Re: [Xen-devel] QEMU build fixes for Xen-4.11

[Juergen Gross]

On 10/05/18 15:54, Anthony PERARD wrote:
> Hi Juergen,
> 
> Do you mind if I backport a GCC-8 fix + a fix for a libusb deprecated
> function? To to be Xen 4.11.

I don't mind at all. Go ahead.


Juergen

> 
> GCC-8 fix:
>> dump: Fix build with newer gcc
>> https://git.qemu.org/?p=qemu.git;a=commit;h=84c868f6b8f8c1be9d3d65df93cf00b30821401c
> 
> libusb fix:
>> Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
>> https://git.qemu.org/?p=qemu.git;a=commit;h=9d8fa0df49af16a208fa961c2968fba4daffcc07
> 
> Regards,
> 


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

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

[Juergen Gross]

On 10/05/18 10:33, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 06:12:28PM +0200, Juergen Gross wrote:
>> On 09/05/18 18:07, Roger Pau Monne wrote:
>>> This prevents page-shattering, by being able to populate the RAM
>>> regions below 4GB using 1GB pages, provided the guest memory size is
>>> set to a multiple of a GB.
>>>
>>> Note that there are some special and ACPI pages in the MMIO hole that
>>> will be populated using smaller order pages, but those shouldn't be
>>> accessed as often as RAM regions.
>>
>> Would it be possible somehow to put a potential firmware into that
>> 1GB region, too, if it needs any memory in high memory? Seabios e.g.
>> is taking the last RAM page of the guest for its hypercall page, which
>> will again shatter GB mappings.
> 
> I know this comment is related to HVM guests, but I'm not sure I see
> how setting the hypercall page shatters GB mappings. Setting the
> hypercall page doesn't involve changing any p2m mappings, but just
> filling a guest RAM page with some data.

The problem is that any memory reserved by firmware will be added as
"Reserved" in the E820 map. This will in turn result to the OS mapping
it read only or not at all, so it can't use a GB mapping even for the
physical memory mapping any longer. Seabios e.g. is using the last
memory page of the guest below 4GB for that purpose. Linux tends to
put memory management structure accessed very often (e.g. struct page
or numa node data) at the end of a memory region, so performance is
degraded. With memory management intensive workloads I've seen
performance going up about 3% in a HVM guest with a small Xen patch
adding a single additional page to the guest which was used by Seabios
for the hypercall page, resulting in the guest using a GB mapping for
the last GB of its memory.


Juergen

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

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

[Souptick Joarder]

On Thu, May 10, 2018 at 11:02 PM, Boris Ostrovsky
 wrote:
> On 05/10/2018 09:53 AM, Souptick Joarder wrote:
>> On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross  wrote:
>>> On 14/04/18 21:15, Souptick Joarder wrote:
 Use new return type vm_fault_t for fault handler
 in struct vm_operations_struct.

 Signed-off-by: Souptick Joarder 
 Reviewed-by: Matthew Wilcox 
>>> Reviewed-by: Juergen Gross 
>>>
>>>
>>> Juergen
>>>
>> Any further comment on this patch ?
>
>
> It is scheduled to go into 4.18.
>
>
> -boris

Thanks Boris :)

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

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

[Souptick Joarder]

On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross  wrote:
> On 14/04/18 21:15, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler
>> in struct vm_operations_struct.
>>
>> Signed-off-by: Souptick Joarder 
>> Reviewed-by: Matthew Wilcox 
>
> Reviewed-by: Juergen Gross 
>
>
> Juergen
>

Any further comment on this patch ?

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

[Xen-devel] [qemu-mainline test] 122645: FAIL

[osstest service owner]

flight 122645 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122645/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken  in 122629
 test-amd64-amd64-xl-qcow2broken  in 122629
 build-arm64-libvirt  broken  in 122629
 test-amd64-i386-libvirt-xsm  broken  in 122629
 build-arm64-pvopsbroken  in 122629
 build-arm64-libvirt4 host-install(4) broken in 122629 REGR. vs. 122357
 build-arm64-xsm4 host-install(4) broken in 122629 REGR. vs. 122357
 build-arm64-pvops  4 host-install(4) broken in 122629 REGR. vs. 122357

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 122629 pass in 122645
 test-amd64-amd64-xl-qcow24 host-install(4) broken in 122629 pass in 122645
 test-armhf-armhf-libvirt-xsm 12 guest-startfail pass in 122629
 test-armhf-armhf-xl-xsm  12 guest-startfail pass in 122629
 test-armhf-armhf-xl  16 guest-start/debian.repeat  fail pass in 122629
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 122629
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail pass in 122629
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail pass in 122629
 test-armhf-armhf-libvirt 16 guest-start/debian.repeat  fail pass in 122629
 test-armhf-armhf-xl-vhd  16 guest-start.2  fail pass in 122629
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat  fail pass in 122629

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked in 122629 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 122629 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 122629 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 122629 n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 122629 like 
122357
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 122629 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 122629 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 122629 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122357
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122357
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122357
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122357
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122357
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 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-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-xl-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

On 10/05/2018, 14:03, "George Dunlap"  wrote:

On 05/10/2018 12:38 PM, George Dunlap wrote:
> On 05/04/2018 09:36 AM, Lars Kurth wrote:
>> The tool covers step 2 of the following workflow
>>
>>   Step 1: git format-patch ... -o  ...
>>   Step 2: ./scripts/add_maintainers.pl -d 
>>   This overwrites  *.patch files in 
>>   Step 3: git send-email -to xen-devel@lists.xenproject.org 
/*.patchxm
>>
>> I manually tested all options and the most common combinations
>> on Mac.
>>
>> Changes since v1:
>> - Added RAB (indicated by Juergen on IRC that this is OK)
>> - Remove trailing whitespaces
>> - Renamed --prefix to --reroll-count
>> - Cleaned up short options -v, ... to be in line with git
>> - Added --tags|-t option to add AB, RAB and RB emails to CC list
>> - Added --insert|-i mode to allow for people adding CCs to commit message
>>   instead of the e-mail header (the header is the default)
>> - Moved common code into functions
>> - Added logic, such that the tool only insert's To: and Cc: statements
>>   which were not there before, allowing for running the tool multiple 
times
>>   on the same 
>>
>> Changes since v2:
>> - Deleted --version and related infrastructure
>> - Added subroutine prototypes
>> - Removed AT and @lists declaration and used \@ in literals
>> - Changed usage message and options based on feedback
>> - Improved error handling
>> - Removed occurances of index() and replaced with regex
>> - Removed non-perl idioms
>> - Moved uniq statements to normalize and added info on what normalize 
does
>> - Read L: tags from MAINTAINERS file instead of using heuristic
>> - Fixed issues related to metacharacters in getmaintainers()
>> - Allow multiple -a | --arg values (because of this renamed --args)
>> - Identify tags via regex
>> - CC's from tags are only inserted in the mail header, never the body
>> - That is unless the new option --tagscc is used
>> - Added policy processing which includes reworking insert()
>> - Replaced -i|--insert with -p|--inspatch and -c|--inscover now using 
policies
>> - Added new policies to cover for all user requests
>> - Rewrote help message to center around usage of policies
>> - Reordered some code (e.g. help string first to make code more easily 
readable)
>>
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Julien Grall 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Signed-off-by: Lars Kurth 
>> Release-acked-by: Juergen Gross 
>> ---
>>  scripts/add_maintainers.pl | 512 
+
>>  1 file changed, 512 insertions(+)
>>  create mode 100755 scripts/add_maintainers.pl
>>
>> diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
>> new file mode 100755
>> index 00..11ae60d888
>> --- /dev/null
>> +++ b/scripts/add_maintainers.pl
>> @@ -0,0 +1,512 @@
>> +#!/usr/bin/perl -w
>> +# (c) 2018, Lars Kurth 
>> +#
>> +# Add maintainers to patches generated with git format-patch
>> +#
>> +# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
>> +#
>> +# Prerequisites: Execute
>> +#git format-patch ... -o  ...
>> +#
>> +#./scripts/get_maintainer.pl is present in the tree
>> +#
>> +# Licensed under the terms of the GNU GPL License version 2
>> +
>> +use strict;
>> +
>> +use Getopt::Long qw(:config no_auto_abbrev);
>> +use File::Basename;
>> +use List::MoreUtils qw(uniq);
>> +
>> +sub getmaintainers ($$$);
>> +sub gettagsfrompatch ($$$;$);
>> +sub normalize ($$);
>> +sub insert ();
>> +sub hastag ($$);
>> +
>> +# Tool Variables
>> +my $tool = $0;
>> +my $usage = <> +USAGE: $tool [options] (--patchdir | -d) 
>> +
>> +OPTIONS:
>> +
>> +  --reroll-count  | -v 
>> +Choose patch files for specific version. This results into the
>> +following filters on 
>> +0: default - *.patch
>> +>1: v*.patch
>> +  --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
>> +Insert email addresses into *.patch files according to the POLICY
>> +See section POLICY:
>> +  --inscover (top|ccend|none) | -c (top|ccend|none)
>> +Insert email addresses into cover letteraccording to the POLICY
>> +See section PROCESSING 

[Xen-devel] [linux-4.14 test] 122644: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm  broken  in 122572
 test-arm64-arm64-xl-xsm  broken  in 122628
 test-arm64-arm64-xl-credit2  broken  in 122628
 build-arm64-libvirt  broken  in 122628
 build-arm64-libvirt4 host-install(4) broken in 122628 REGR. vs. 122368

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 122572 pass in 122644
 test-arm64-arm64-xl-credit2  4 host-install(4) broken in 122628 pass in 122644
 test-arm64-arm64-xl-xsm  4 host-install(4) broken in 122628 pass in 122644
 test-arm64-arm64-examine  5 host-install broken pass in 122628
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 122628 pass in 122644
 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat  fail pass in 122572
 test-armhf-armhf-xl-arndale  12 guest-startfail pass in 122628
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 122628
 test-armhf-armhf-xl-xsm  16 guest-start/debian.repeat  fail pass in 122628
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail pass in 122628

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 122628 n/a
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 122628 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 122628 never 
pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-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-qemut-win7-amd64 17 guest-stop fail never pass
 

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Stefano Stabellini]

On Thu, 10 May 2018, Praveen Kumar wrote:
> > Yeah, you are right. It looks like turning Dom0 into a DomU is not good
> > enough. Maybe for this option to be viable we would actually have to
> > terminate (or pause and never unpause?) dom0 after boot.
> 
> Just a thought !
> How about keeping Dom0 still be there, but DomUs given Dom0 privilege, with
> restricted permission on mission critical resources ? And if anyhow Dom0
> crashes,
> the best contended among the existing DomUs take the ownership of Dom0 ?

I don't think this is easily doable, also it wouldn't solve the issue of
removing dom0 from the system. But see below.


> > > However, you surely need an entity to handle domain crash. You don't
> want to
> > > reboot your platform (and therefore you safety critical domain) for a
> crashed
> > > UI, right? So how this is going to be handled in your option?
> 
> > We need to understand the certification requirements better to know the
> > answer to this. I am guessing that UI crashes are not handled from the
> > certification point of view -- maybe we only need to demonstrate that
> > the system is not affected by them?
> 
> Where can we find the certification requirements details ?

Yes, I think we need to understand the requirements better to figure out
the right way forward for Dom0.

For instance, here is another idea: we could have Xen boot multiple
domains at boot time from device tree, as suggested in the dom0-less
approach. All of the domains booted from Xen are "mission-critical". The
first domain could still be dom0. Once booted, Dom0 can start other VMs,
however, Xen would restrict Dom0 from doing any operations affecting the
first set of mission-critical domains.

This way, we would get the flexibility of being able to start/stop
domains at run time, but at the same time we might still be able to
avoid certifications for Dom0, because Dom0 cannot affect the mission
critical applications.

Is this approach actually feasible? We need to read the requirements to
know. I am hoping Artem will chime in on this :-)

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

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

[Boris Ostrovsky]

On 05/10/2018 09:53 AM, Souptick Joarder wrote:
> On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross  wrote:
>> On 14/04/18 21:15, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler
>>> in struct vm_operations_struct.
>>>
>>> Signed-off-by: Souptick Joarder 
>>> Reviewed-by: Matthew Wilcox 
>> Reviewed-by: Juergen Gross 
>>
>>
>> Juergen
>>
> Any further comment on this patch ?


It is scheduled to go into 4.18.


-boris

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

[Xen-devel] [PATCH 0/5] PVH MTRR initial state

[Roger Pau Monne]

Hello,

The following patches set a sane initial MTRR state for both Dom0 and
DomU PVH guests. Note that for Dom0 the host MTRR state is used, OTOH
for DomU the default MTRR type is set to write-back.

This should avoid guests having to setup some kind of MTRR state in
order to boot.

Thanks, Roger.

Roger Pau Monne (5):
  hvm/mtrr: add emacs local variables block with formatting info
  hvm/mtrr: use the hardware number of variable ranges for Dom0
  hvm/mtrr: copy hardware state for Dom0
  libxc/pvh: set default MTRR type to write-back
  docs/pvh: document initial MTRR state

 docs/misc/pvh.markdown   | 15 +
 tools/libxc/xc_dom_x86.c | 44 ++
 xen/arch/x86/hvm/mtrr.c  | 46 ++--
 3 files changed, 103 insertions(+), 2 deletions(-)

-- 
2.17.0


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

[Xen-devel] [PATCH 5/5] docs/pvh: document initial MTRR state

[Roger Pau Monne]

Provided to both Dom0 and DomUs.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/pvh.markdown | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/docs/misc/pvh.markdown b/docs/misc/pvh.markdown
index e85fb15374..639401a887 100644
--- a/docs/misc/pvh.markdown
+++ b/docs/misc/pvh.markdown
@@ -92,3 +92,18 @@ event channels. Delivery of those interrupts can be 
configured in the same way
 as HVM guests, check xen/include/public/hvm/params.h and
 xen/include/public/hvm/hvm\_op.h for more information about available delivery
 methods.
+
+## MTRR ##
+
+### Unprivileged guests ###
+
+PVH guests are booted with the default MTRR type set to write-back and MTRR
+enabled. This allows DomUs to start with a sane MTRR state. Note that this will
+have to be revisited when pci-passthrough is added to PVH in order to set MMIO
+regions as UC.
+
+### Hardware domain ###
+
+A PVH hardware domain is booted with the same MTRR state as the one found on
+the host. This is done because the hardware domain memory map is already a
+modified copy of the host memory map, so the same MTRR setup should work.
-- 
2.17.0


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

[Xen-devel] [PATCH 4/5] libxc/pvh: set default MTRR type to write-back

[Roger Pau Monne]

And enable MTRR. This allows to provide a sane initial MTRR state for
PVH DomUs. This will have to be expanded when pci-passthrough support
is added to PVH guests, so that MMIO regions of devices are set as
UC.

Note that initial MTRR setup is done by hvmloader for HVM guests,
that's not used by PVH guests.

Signed-off-by: Roger Pau Monné 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libxc/xc_dom_x86.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index e33a28847d..d28ff4d7e9 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -53,6 +53,9 @@
 #define X86_CR0_PE 0x01
 #define X86_CR0_ET 0x10
 
+#define MTRR_TYPE_WRBACK 6
+#define MTRR_DEF_TYPE_ENABLE (1u << 11)
+
 #define SPECIALPAGE_PAGING   0
 #define SPECIALPAGE_ACCESS   1
 #define SPECIALPAGE_SHARING  2
@@ -931,6 +934,20 @@ static int vcpu_x86_64(struct xc_dom_image *dom)
 return rc;
 }
 
+const static void *hvm_get_save_record(const void *ctx, unsigned int type,
+   unsigned int instance)
+{
+const struct hvm_save_descriptor *header;
+
+for ( header = ctx;
+  header->typecode != HVM_SAVE_CODE(END);
+  ctx += sizeof(*header) + header->length, header = ctx )
+if ( header->typecode == type && header->instance == instance )
+return ctx + sizeof(*header);
+
+return NULL;
+}
+
 static int vcpu_hvm(struct xc_dom_image *dom)
 {
 struct {
@@ -938,9 +955,12 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 HVM_SAVE_TYPE(HEADER) header;
 struct hvm_save_descriptor cpu_d;
 HVM_SAVE_TYPE(CPU) cpu;
+struct hvm_save_descriptor mtrr_d;
+HVM_SAVE_TYPE(MTRR) mtrr;
 struct hvm_save_descriptor end_d;
 HVM_SAVE_TYPE(END) end;
 } bsp_ctx;
+const HVM_SAVE_TYPE(MTRR) *mtrr_record;
 uint8_t *full_ctx = NULL;
 int rc;
 
@@ -1014,6 +1034,30 @@ static int vcpu_hvm(struct xc_dom_image *dom)
 if ( dom->start_info_seg.pfn )
 bsp_ctx.cpu.rbx = dom->start_info_seg.pfn << PAGE_SHIFT;
 
+/* Set the MTRR. */
+bsp_ctx.mtrr_d.typecode = HVM_SAVE_CODE(MTRR);
+bsp_ctx.mtrr_d.instance = 0;
+bsp_ctx.mtrr_d.length = HVM_SAVE_LENGTH(MTRR);
+
+mtrr_record = hvm_get_save_record(full_ctx, HVM_SAVE_CODE(MTRR), 0);
+if ( !mtrr_record )
+{
+xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
+ "%s: unable to get MTRR save record", __func__);
+goto out;
+}
+
+memcpy(_ctx.mtrr, mtrr_record, sizeof(bsp_ctx.mtrr));
+
+/* TODO: maybe this should be a firmware option instead? */
+if ( !dom->device_model )
+/*
+ * Enable MTRR, set default type to WB.
+ * TODO: add MMIO areas as UC when passthrough is supported.
+ */
+bsp_ctx.mtrr.msr_mtrr_def_type = MTRR_TYPE_WRBACK |
+ MTRR_DEF_TYPE_ENABLE;
+
 /* Set the end descriptor. */
 bsp_ctx.end_d.typecode = HVM_SAVE_CODE(END);
 bsp_ctx.end_d.instance = 0;
-- 
2.17.0


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

[Xen-devel] [PATCH 2/5] hvm/mtrr: use the hardware number of variable ranges for Dom0

[Roger Pau Monne]

Expand the size of the variable ranges array to match the size of the
underlying hardware, this is a preparatory change for copying the
hardware MTRR state for Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/mtrr.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index b3c08c3977..95a3deabea 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -154,14 +154,17 @@ uint8_t pat_type_2_pte_flags(uint8_t pat_type)
 int hvm_vcpu_cacheattr_init(struct vcpu *v)
 {
 struct mtrr_state *m = >arch.hvm_vcpu.mtrr;
+unsigned int num_var_ranges =
+is_hardware_domain(v->domain) ? (mtrr_state.mtrr_cap & 0xff)
+  : MTRR_VCNT;
 
 memset(m, 0, sizeof(*m));
 
-m->var_ranges = xzalloc_array(struct mtrr_var_range, MTRR_VCNT);
+m->var_ranges = xzalloc_array(struct mtrr_var_range, num_var_ranges);
 if ( m->var_ranges == NULL )
 return -ENOMEM;
 
-m->mtrr_cap = (1u << 10) | (1u << 8) | MTRR_VCNT;
+m->mtrr_cap = (1u << 10) | (1u << 8) | num_var_ranges;
 
 v->arch.hvm_vcpu.pat_cr =
 ((uint64_t)PAT_TYPE_WRBACK) |   /* PAT0: WB */
@@ -683,6 +686,9 @@ static int hvm_save_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 | (mtrr_state->enabled << 10);
 hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
 
+if ( (mtrr_state->mtrr_cap & 0xff) != MTRR_VCNT )
+return -EINVAL;
+
 for ( i = 0; i < MTRR_VCNT; i++ )
 {
 /* save physbase */
@@ -727,6 +733,9 @@ static int hvm_load_mtrr_msr(struct domain *d, 
hvm_domain_context_t *h)
 
 mtrr_state->mtrr_cap = hw_mtrr.msr_mtrr_cap;
 
+if ( (mtrr_state->mtrr_cap & 0xff) != MTRR_VCNT )
+return -EINVAL;
+
 for ( i = 0; i < NUM_FIXED_MSR; i++ )
 mtrr_fix_range_msr_set(d, mtrr_state, i, hw_mtrr.msr_mtrr_fixed[i]);
 
-- 
2.17.0


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

[Xen-devel] [PATCH 3/5] hvm/mtrr: copy hardware state for Dom0

[Roger Pau Monne]

Copy the state found on the hardware when creating a PVH Dom0. Since
the memory map provided to a PVH Dom0 is based on the native one using
the same set of MTRR ranges should provide Dom0 with a sane MTRR state
without having to manually build it in Xen.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/mtrr.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 95a3deabea..1cb000388a 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -176,6 +176,29 @@ int hvm_vcpu_cacheattr_init(struct vcpu *v)
 ((uint64_t)PAT_TYPE_UC_MINUS << 48) |   /* PAT6: UC- */
 ((uint64_t)PAT_TYPE_UNCACHABLE << 56);  /* PAT7: UC */
 
+if ( is_hardware_domain(v->domain) )
+{
+/* Copy values from the host. */
+struct domain *d = v->domain;
+unsigned int i;
+
+if ( mtrr_state.have_fixed )
+for ( i = 0; i < NUM_FIXED_MSR; i++ )
+mtrr_fix_range_msr_set(d, m, i,
+  ((uint64_t 
*)mtrr_state.fixed_ranges)[i]);
+
+for ( i = 0; i < num_var_ranges; i++ )
+{
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSBASE(i),
+   mtrr_state.var_ranges[i].base);
+mtrr_var_range_msr_set(d, m, MSR_IA32_MTRR_PHYSMASK(i),
+   mtrr_state.var_ranges[i].mask);
+}
+
+mtrr_def_type_msr_set(d, m, mtrr_state.def_type |
+(mtrr_state.enabled << 10));
+}
+
 return 0;
 }
 
-- 
2.17.0


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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Thu, 2018-05-10 at 17:49 +0200, Mirela Simonovic wrote:
> Regardless of the fact that the notifier returns an error or not, I
> believe it would be good and safe to set priority and document that
> priority zero would cause racing issue in the scenario I debugged
> today. I'm pretty sure that this discussion would be forgotten soon
> and it really should be documented in code/comment.
> 
I may very well be missing or misunderstanding something, but I
continue to think that the problem here is that CPU_STARTING can't,
right now, fail, while you need it to be able to.

If that is the case, giving different priorities to the notifier, is
not a solution.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Thu, 2018-05-10 at 17:02 +0100, Julien Grall wrote:
> On 10/05/18 16:49, Mirela Simonovic wrote:
> > Regardless of the fact that the notifier returns an error or not, I
> > believe it would be good and safe to set priority and document that
> > priority zero would cause racing issue in the scenario I debugged
> > today. I'm pretty sure that this discussion would be forgotten soon
> > and it really should be documented in code/comment.
> > 
> > In emails above I assumed we'll stop the erroneous CPU. I didn't
> > have
> > a chance to try returning an error until few minutes ago.
> > I tried returning an error from the notifier now and the whole
> > system
> > fails. You realized according to the answer below that this is
> > going
> > to happen.
> 
> I was aware about it since the beginning. The whole point of the 
> conversation was we should avoid to take the decision at the lower
> level 
> and let the upper layer decide what to do.
> 
This makes sense to me.

> > I would rather stop CPU because changing notify_cpu_starting
> > affects
> > x86 as well, I cannot dig into that and it would be really to much
> > for
> > this series. Since you're fine with stopping cpu as well, please
> > lets
> > do that instead of escalating this to who knows where :)
> 
> Also, while I suggest that it could be replaced by stop_cpu() in the 
> common code, I also suggested that notifier_cpu_starting() could
> return 
> an error then the architecture specific code can decide what to do.
> 
> On x86 it would still be a BUG_ON(notifier_cpu_starting()). On Arm
> we 
> can decide what to do. But it is not part of that discussion here.
> 
As just saind in the other email, I don't think this is all it's
necessary to enable CPU_STARTING to fail.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Thu, 2018-05-10 at 16:13 +0100, Julien Grall wrote:
> On 10/05/18 16:00, Mirela Simonovic wrote:
> > > If you add your callback to CPU_UP_PREPARE, instead than to
> > > CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without
> > > having
> > > to fiddle with priorities.
> 
> This function will enable capabilities on a given CPU, most of them
> are 
> touching system registers. So it is necessary to add the callback to 
> CPU_STARTING.
> 
Right, I guess that answers my question.

> I always like to understand what I maintain :). Why do you need to 
> change the priority if you just return an error in the notifier?
> 
> At the moment, notify_cpu_starting has a BUG_ON() in it. But ideally
> I 
> would like to either replace that BUG_ON by cpu_stop or just
> returning 
> an error to give a chance of the architecture deciding what to do
> (this 
> does not have to be done today).
> 
The problem is that, currently, once we've reached CPU_STARTING, we
assume that the CPU bringup has gone ok, and things can't fail.

Therefore, the only place when we undo what CPU_STARTING does is during
CPU_DEAD, i.e., during hotunplug/suspend/teardown.

I understand the point of having to run stuff on the CPU that is coming
up, as well as your more general point.

However, I don't know whether allowing CPU_STARTING to fail is the best
way to achieve what you want to achieve, nor whether the BUG_ON in
notify_cpu_starting() is the only issue you'll face trying to do that.

I'd say that, if CPU_STARTING can fail, we need an appropriate rollback
step, i.e., the flow must become something like (but I'd appreciate the
opinion of x86 and core hypervisor maintainers about this):

CPU_UP_PREPARE --> CPU_STARTING xx> CPU_DIDNT_START --> CPU_UP_CANCEL

At which point, e.g., from the scheduler point of view, we can try to
put a call to SCHED_OP(deinit_pdata) in CPU_DIDNT_START, and that would
avoid the problem Mirela is facing, without having to play with
priorities.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Stefano Stabellini]

On Thu, 10 May 2018, Olaf Hering wrote:
> Am Wed, 9 May 2018 14:43:17 -0700 (PDT)
> schrieb Stefano Stabellini :
> 
> > 512b109ec962 is a very old commit: why is it causing problems to Xen
> > 4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I
> > might be missing some context.
> 
> It is papering over the real issue, thats why one can still migrate a
> pvops HVM domU with current toolstack. Upstream kernel simply does the
> work that is supposed to be done by qemu itself. Since the xenlinux based
> kernel does not do that work (it never had a need to do the unplug twice),
> migration fails.
> 
> qemu has to carry the unplug state from one dom0 to another dom0 during
> migration, simply because unplug is a one-time operation that can not 
> be undone. I wonder how to do that, if qemu already has code to carry its
> state.

You could add a property to vmstate_xen_platform of xen_platform.c, but
you need to pay attention to legacy compatibility. Inevitably, there
will be older versions that do not have the new vmstate_xen_platform
field or do not set it properly.

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall]

On 10/05/18 16:49, Mirela Simonovic wrote:

Hi Julien,


Hi,


On Thu, May 10, 2018 at 5:13 PM, Julien Grall  wrote:



On 10/05/18 16:00, Mirela Simonovic wrote:


Hi Dario,

On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli 
wrote:


On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote:


On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic


Please take a look at function cpu_schedule_callback in schedule.c.
Within switch, case CPU_DEAD doesn't have a break, causing the
bellow
CPU_UP_CANCELED to execute as well when the CPU goes down. This
looks
wrong to me.
Dario, could you please confirm that this is a bug? Otherwise could
you please confirm the reasoning beyond?



Dario sorry, this looked wrong in my scenario but actually it is
correct. I understand the purpose of the missing break now.


No problem.


For the curious ones (if any) here is detailed description: errata
notifier added in this patch had the same priority as scheduler
notifier. I though priority doesn't matter, but I was wrong. In this
particular scenario where a CPU fails to enable capabilities
(triggered by errata notifier added in this patch), scheduler
callback
executed before the errata callback for CPU_STARTING event.


So, you're adding your errata callback to the CPU_STARTING notifier,
right? (Sorry for having to ask, I don't have the patch handy right
now.)


In other
words, scheduler already called init_pdata before the errata callback
fired (and stopped the CPU).
Later on when errata callback fired, enabling of capabilities has
failed, so the erroneous non-boot CPU stopped itself and never
declared to be online.
Then CPU#0 fired new notification with CPU_UP_CANCELED event in order
to clean up for the job done on CPU_STARTING. However, this broke the
assumption (which is good) made in cpu_schedule_callback. The
assumption is that the sequence of steps should be
alloc_pdata-->init_pdata-->deinit_pdata-->free_pdata. In this
particular case deinit_pdata was not done because this would be done
only upon CPU_DEAD event which makes no sense in this scenario.
In order to avoid running into the invalid scenario described above,
the errata callback should fire before the scheduler callback. If
enabling capabilities fails, the scheduler callback for CPU_STARTING
will never execute afterwards, so the following CPU_UP_CANCELED event
triggered by the CPU#0 will do free_pdata, which is ok because
init_pdata was not executed and alloc_pdata-->free_pdata flow is also
valid. Congratulations to the reader who reached this point :)


Ok, but the flow is, AFAICR, CPU_UP_PREPARE->CPU_STARTING->CPU_ONLINE.

If you add your callback to CPU_UP_PREPARE, instead than to
CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without having
to fiddle with priorities.


This function will enable capabilities on a given CPU, most of them are
touching system registers. So it is necessary to add the callback to
CPU_STARTING.





Difference between CPU_UP_PREPARE and CPU_STARTING (in addition to the
sequential ordering) is about which CPU executes the callback.
In CPU_UP_PREPARE case the CPU which called cpu_up for another CPU
will execute the callback. If I have 2 CPUs: CPU#0 executes callback
when trying to hotplug CPU#1. I need CPU#1 to execute this callback.
In CPU_STARTING case the CPU#1 will execute the callback, that is the
reason why it has to be CPU_STARTING event.

I tried CPU_UP_PREPARE in my tuned scenario and I needed few moment to
realize why the system died (CPU#0 stopped himself :)


Is there any reason why you can't do it that way? It would look more
natural to me, and it's definitely going to be easier debug and
maintain (e.g., look at how many callbacks CPU_UP_PREPARE has, as
compared to CPU_STARTING ;-P).



Julien is going to maintain this :)))



I always like to understand what I maintain :). Why do you need to change
the priority if you just return an error in the notifier?



Regardless of the fact that the notifier returns an error or not, I
believe it would be good and safe to set priority and document that
priority zero would cause racing issue in the scenario I debugged
today. I'm pretty sure that this discussion would be forgotten soon
and it really should be documented in code/comment.

In emails above I assumed we'll stop the erroneous CPU. I didn't have
a chance to try returning an error until few minutes ago.
I tried returning an error from the notifier now and the whole system
fails. You realized according to the answer below that this is going
to happen.


I was aware about it since the beginning. The whole point of the 
conversation was we should avoid to take the decision at the lower level 
and let the upper layer decide what to do.


If the system is failing today then that's fine and still fit what I 
said in my first e-mail of that thread. For reminder:


"We should really avoid to use panic(...) if this is something the 
system can survive. In that specific case, it 

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi Julien,

On Thu, May 10, 2018 at 5:13 PM, Julien Grall  wrote:
>
>
> On 10/05/18 16:00, Mirela Simonovic wrote:
>>
>> Hi Dario,
>>
>> On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli 
>> wrote:
>>>
>>> On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote:

 On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic

> Please take a look at function cpu_schedule_callback in schedule.c.
> Within switch, case CPU_DEAD doesn't have a break, causing the
> bellow
> CPU_UP_CANCELED to execute as well when the CPU goes down. This
> looks
> wrong to me.
> Dario, could you please confirm that this is a bug? Otherwise could
> you please confirm the reasoning beyond?
>

 Dario sorry, this looked wrong in my scenario but actually it is
 correct. I understand the purpose of the missing break now.

>>> No problem.
>>>
 For the curious ones (if any) here is detailed description: errata
 notifier added in this patch had the same priority as scheduler
 notifier. I though priority doesn't matter, but I was wrong. In this
 particular scenario where a CPU fails to enable capabilities
 (triggered by errata notifier added in this patch), scheduler
 callback
 executed before the errata callback for CPU_STARTING event.

>>> So, you're adding your errata callback to the CPU_STARTING notifier,
>>> right? (Sorry for having to ask, I don't have the patch handy right
>>> now.)
>>>
 In other
 words, scheduler already called init_pdata before the errata callback
 fired (and stopped the CPU).
 Later on when errata callback fired, enabling of capabilities has
 failed, so the erroneous non-boot CPU stopped itself and never
 declared to be online.
 Then CPU#0 fired new notification with CPU_UP_CANCELED event in order
 to clean up for the job done on CPU_STARTING. However, this broke the
 assumption (which is good) made in cpu_schedule_callback. The
 assumption is that the sequence of steps should be
 alloc_pdata-->init_pdata-->deinit_pdata-->free_pdata. In this
 particular case deinit_pdata was not done because this would be done
 only upon CPU_DEAD event which makes no sense in this scenario.
 In order to avoid running into the invalid scenario described above,
 the errata callback should fire before the scheduler callback. If
 enabling capabilities fails, the scheduler callback for CPU_STARTING
 will never execute afterwards, so the following CPU_UP_CANCELED event
 triggered by the CPU#0 will do free_pdata, which is ok because
 init_pdata was not executed and alloc_pdata-->free_pdata flow is also
 valid. Congratulations to the reader who reached this point :)

>>> Ok, but the flow is, AFAICR, CPU_UP_PREPARE->CPU_STARTING->CPU_ONLINE.
>>>
>>> If you add your callback to CPU_UP_PREPARE, instead than to
>>> CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without having
>>> to fiddle with priorities.
>
> This function will enable capabilities on a given CPU, most of them are
> touching system registers. So it is necessary to add the callback to
> CPU_STARTING.
>
>>>
>>
>> Difference between CPU_UP_PREPARE and CPU_STARTING (in addition to the
>> sequential ordering) is about which CPU executes the callback.
>> In CPU_UP_PREPARE case the CPU which called cpu_up for another CPU
>> will execute the callback. If I have 2 CPUs: CPU#0 executes callback
>> when trying to hotplug CPU#1. I need CPU#1 to execute this callback.
>> In CPU_STARTING case the CPU#1 will execute the callback, that is the
>> reason why it has to be CPU_STARTING event.
>>
>> I tried CPU_UP_PREPARE in my tuned scenario and I needed few moment to
>> realize why the system died (CPU#0 stopped himself :)
>>
>>> Is there any reason why you can't do it that way? It would look more
>>> natural to me, and it's definitely going to be easier debug and
>>> maintain (e.g., look at how many callbacks CPU_UP_PREPARE has, as
>>> compared to CPU_STARTING ;-P).
>>>
>>
>> Julien is going to maintain this :)))
>
>
> I always like to understand what I maintain :). Why do you need to change
> the priority if you just return an error in the notifier?
>

Regardless of the fact that the notifier returns an error or not, I
believe it would be good and safe to set priority and document that
priority zero would cause racing issue in the scenario I debugged
today. I'm pretty sure that this discussion would be forgotten soon
and it really should be documented in code/comment.

In emails above I assumed we'll stop the erroneous CPU. I didn't have
a chance to try returning an error until few minutes ago.
I tried returning an error from the notifier now and the whole system
fails. You realized according to the answer below that this is going
to happen.

> At the moment, notify_cpu_starting has a BUG_ON() in it. But ideally I would
> like to either replace that BUG_ON by cpu_stop or just 

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi Dario,

On Thu, May 10, 2018 at 4:25 PM, Dario Faggioli  wrote:
> On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote:
>> On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
>>
>> > Please take a look at function cpu_schedule_callback in schedule.c.
>> > Within switch, case CPU_DEAD doesn't have a break, causing the
>> > bellow
>> > CPU_UP_CANCELED to execute as well when the CPU goes down. This
>> > looks
>> > wrong to me.
>> > Dario, could you please confirm that this is a bug? Otherwise could
>> > you please confirm the reasoning beyond?
>> >
>>
>> Dario sorry, this looked wrong in my scenario but actually it is
>> correct. I understand the purpose of the missing break now.
>>
> No problem.
>
>> For the curious ones (if any) here is detailed description: errata
>> notifier added in this patch had the same priority as scheduler
>> notifier. I though priority doesn't matter, but I was wrong. In this
>> particular scenario where a CPU fails to enable capabilities
>> (triggered by errata notifier added in this patch), scheduler
>> callback
>> executed before the errata callback for CPU_STARTING event.
>>
> So, you're adding your errata callback to the CPU_STARTING notifier,
> right? (Sorry for having to ask, I don't have the patch handy right
> now.)
>
>> In other
>> words, scheduler already called init_pdata before the errata callback
>> fired (and stopped the CPU).
>> Later on when errata callback fired, enabling of capabilities has
>> failed, so the erroneous non-boot CPU stopped itself and never
>> declared to be online.
>> Then CPU#0 fired new notification with CPU_UP_CANCELED event in order
>> to clean up for the job done on CPU_STARTING. However, this broke the
>> assumption (which is good) made in cpu_schedule_callback. The
>> assumption is that the sequence of steps should be
>> alloc_pdata-->init_pdata-->deinit_pdata-->free_pdata. In this
>> particular case deinit_pdata was not done because this would be done
>> only upon CPU_DEAD event which makes no sense in this scenario.
>> In order to avoid running into the invalid scenario described above,
>> the errata callback should fire before the scheduler callback. If
>> enabling capabilities fails, the scheduler callback for CPU_STARTING
>> will never execute afterwards, so the following CPU_UP_CANCELED event
>> triggered by the CPU#0 will do free_pdata, which is ok because
>> init_pdata was not executed and alloc_pdata-->free_pdata flow is also
>> valid. Congratulations to the reader who reached this point :)
>>
> Ok, but the flow is, AFAICR, CPU_UP_PREPARE->CPU_STARTING->CPU_ONLINE.
>
> If you add your callback to CPU_UP_PREPARE, instead than to
> CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without having
> to fiddle with priorities.
>

Difference between CPU_UP_PREPARE and CPU_STARTING (in addition to the
sequential ordering) is about which CPU executes the callback.
In CPU_UP_PREPARE case the CPU which called cpu_up for another CPU
will execute the callback. If I have 2 CPUs: CPU#0 executes callback
when trying to hotplug CPU#1. I need CPU#1 to execute this callback.
In CPU_STARTING case the CPU#1 will execute the callback, that is the
reason why it has to be CPU_STARTING event.

I tried CPU_UP_PREPARE in my tuned scenario and I needed few moment to
realize why the system died (CPU#0 stopped himself :)

> Is there any reason why you can't do it that way? It would look more
> natural to me, and it's definitely going to be easier debug and
> maintain (e.g., look at how many callbacks CPU_UP_PREPARE has, as
> compared to CPU_STARTING ;-P).
>

Julien is going to maintain this :)))

> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall]

On 10/05/18 15:12, Mirela Simonovic wrote:

Hi Julien,

On Thu, May 10, 2018 at 3:29 PM, Julien Grall  wrote:

Hi,

On 05/10/2018 02:24 PM, Mirela Simonovic wrote:


On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
 wrote:




I have tested the tuned scenario where enabling capabilities fails -
the erroneous CPU is stopped/powered down and the system continues to
work fine without it. Although I still don't understand why indeed I
needed to debug this I'll add the fix in v4.



I don't understand your last sentence. What did you mean?



I still don't understand how can this scenario happen practically at
runtime (a scenario without me tuning the failure for testing).


error path are by nature hard to reach without tweaking the code. 
Imagine something that can only happen once every thousand boot. It is 
not often, but thanks to murphy that will only happen at the worst 
moment. And you know very well how it is a pain to debug :).


So I always tend to tweak the code in order to exercise major error path.


Memory
allocation failure shouldn't be possible at this point and any
workaround related failure would have happened at boot.
I don't see
anything else or my understanding may not be correct...
However, if some new capability would be introduced one day and it
could fail, it would be good if we don't have to go back and fix this
patch.


The memory failure was an example among the other. The whole point here 
is you can't extrapolate how the errata are implemented today for future 
one. I also want to limit the number of stop_cpu/panic over the code, so 
we have only place to make the decision if something is wrong.



At the end, it doesn't matter since the system will be able to
properly deal with such a scenario with the fix.


I would be ok having stop_cpu called here. Although my preference is 
returning an error and let the caller decides what to do.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Thu, 2018-05-10 at 15:24 +0200, Mirela Simonovic wrote:
> On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
> 
> > Please take a look at function cpu_schedule_callback in schedule.c.
> > Within switch, case CPU_DEAD doesn't have a break, causing the
> > bellow
> > CPU_UP_CANCELED to execute as well when the CPU goes down. This
> > looks
> > wrong to me.
> > Dario, could you please confirm that this is a bug? Otherwise could
> > you please confirm the reasoning beyond?
> > 
> 
> Dario sorry, this looked wrong in my scenario but actually it is
> correct. I understand the purpose of the missing break now.
> 
No problem.

> For the curious ones (if any) here is detailed description: errata
> notifier added in this patch had the same priority as scheduler
> notifier. I though priority doesn't matter, but I was wrong. In this
> particular scenario where a CPU fails to enable capabilities
> (triggered by errata notifier added in this patch), scheduler
> callback
> executed before the errata callback for CPU_STARTING event. 
>
So, you're adding your errata callback to the CPU_STARTING notifier,
right? (Sorry for having to ask, I don't have the patch handy right
now.)

> In other
> words, scheduler already called init_pdata before the errata callback
> fired (and stopped the CPU).
> Later on when errata callback fired, enabling of capabilities has
> failed, so the erroneous non-boot CPU stopped itself and never
> declared to be online.
> Then CPU#0 fired new notification with CPU_UP_CANCELED event in order
> to clean up for the job done on CPU_STARTING. However, this broke the
> assumption (which is good) made in cpu_schedule_callback. The
> assumption is that the sequence of steps should be
> alloc_pdata-->init_pdata-->deinit_pdata-->free_pdata. In this
> particular case deinit_pdata was not done because this would be done
> only upon CPU_DEAD event which makes no sense in this scenario.
> In order to avoid running into the invalid scenario described above,
> the errata callback should fire before the scheduler callback. If
> enabling capabilities fails, the scheduler callback for CPU_STARTING
> will never execute afterwards, so the following CPU_UP_CANCELED event
> triggered by the CPU#0 will do free_pdata, which is ok because
> init_pdata was not executed and alloc_pdata-->free_pdata flow is also
> valid. Congratulations to the reader who reached this point :)
> 
Ok, but the flow is, AFAICR, CPU_UP_PREPARE->CPU_STARTING->CPU_ONLINE.

If you add your callback to CPU_UP_PREPARE, instead than to
CPU_STARTING, SCHED_OP(init_pdata) wouldn't be called, without having
to fiddle with priorities.

Is there any reason why you can't do it that way? It would look more
natural to me, and it's definitely going to be easier debug and
maintain (e.g., look at how many callbacks CPU_UP_PREPARE has, as
compared to CPU_STARTING ;-P).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] QEMU build fixes for Xen-4.11

[Anthony PERARD]

Hi Juergen,

Do you mind if I backport a GCC-8 fix + a fix for a libusb deprecated
function? To to be Xen 4.11.

GCC-8 fix:
> dump: Fix build with newer gcc
> https://git.qemu.org/?p=qemu.git;a=commit;h=84c868f6b8f8c1be9d3d65df93cf00b30821401c

libusb fix:
> Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
> https://git.qemu.org/?p=qemu.git;a=commit;h=9d8fa0df49af16a208fa961c2968fba4daffcc07

Regards,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Dario Faggioli]

On Thu, 2018-05-10 at 13:57 +0200, Mirela Simonovic wrote:
> Hi,
> 
> +Dario
> 
Thanks.

> On Wed, May 9, 2018 at 6:32 PM, Julien Grall 
> wrote:
> > If there is a bug in the scheduler it should be fixed rather trying
> > to
> > workaround with a panic in the code. If you provide more details,
> > we might
> > be able to help here.
> > 
> 
> This flow seems to have several bugs. Lets start from here:
> 
> Please take a look at function cpu_schedule_callback in schedule.c.
> Within switch, case CPU_DEAD doesn't have a break, causing the bellow
> CPU_UP_CANCELED to execute as well when the CPU goes down. This looks
> wrong to me.
> Dario, could you please confirm that this is a bug? 
>
No, that is entirely on purpose (as you can tell from the
"/* Fallthrough */" comment).

> Otherwise could
> you please confirm the reasoning beyond?
> 
Well, the idea is that the CPU_UP_CANCELLED notifier should _only_
invoke cpu_schedule_down(). On the other hand, the CPU_DEAD notifier
should invoke both:
 SCHED_OP(deinit_pdata)
 cpu_schedule_down()

and the fallthrough is the way we achieve that.

On x86, the shutdown/suspend path is as follows:

XENPF_enter_acpi_sleep (platform_hypercall.c)
  acpi_enter_sleep()
continue_hypercall_on_cpu(0, enter_state_helper)
  enter_state()
system_state = SYS_STATE_suspend
disable_nonboot_cpus()
  for_each_online_cpu ( cpu ) { 
cpu_down(cpu) }
  notifier_call_chain(CPU_DOWN_PREPARE)
cpu_callback(CPU_DOWN_PREPARE)
  cpupool_cpu_remove(cpu)
  cpufreq_del_cpu(cpu)
  stop_machine_run(take_cpu_down, cpu)
__cpu_disable();
  notifier_call_chain(CPU_DYING)
...
  cpumask_clear_cpu(cpu, _online_map);
cpu_disable_scheduler(cpu);
  __cpu_die(cpu)
while ( (seen_state = cpu_state) != CPU_STATE_DEAD ) { ... }
notifier_call_chain(CPU_DEAD)
  cpu_schedule_callback(CPU_DEAD)
...
...
cpu_schedule_callback(CPU_DEAD)
  SCHED_OP(deinit_pdata)
  cpu_schedule_down(cpu)
SCHED_OP(free_pdata)
SCHED_OP(free_vdata)


If you see a BUG_ON triggering, please provide details about that, and
we'll try to figure out what's causing it.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Julien Grall]

Hi,

On 05/10/2018 02:24 PM, Mirela Simonovic wrote:

On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
 wrote:



I have tested the tuned scenario where enabling capabilities fails -
the erroneous CPU is stopped/powered down and the system continues to
work fine without it. Although I still don't understand why indeed I
needed to debug this I'll add the fix in v4.


I don't understand your last sentence. What did you mean?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/3] checkpatch: generalize xen handle matching in the list of types

[Eric Blake]

On 05/10/2018 04:15 AM, Paul Durrant wrote:

All the xen stable APIs define handle types of the form:

_handle

and some define additional handle types of the form:

__handle


Maybe worth mentioning that  always has a 'xen' prefix, 
and/or spelling it:


xen_handle
xen__handle



Examples of these are xenforeignmemory_handle and
xenforeignmemory_resource_handle.

Both of these types will be misparsed by checkpatch if they appear as the
first token in a line since, as types defined by an external library, they
do not conform to the QEMU CODING_STYLE, which suggests CamelCase.

A previous patch (5ac067a24a8) added xendevicemodel_handle to the list
of types. This patch changes that to xen\w+_handle such that it will
match all Xen stable API handles of the forms detailed above.


Nice use of a regex.



Signed-off-by: Paul Durrant 
---
Cc: Eric Blake 
Cc: Paolo Bonzini 
Cc: Daniel P. Berrange 

v2:
  - New in this version


Reviewed-by: Eric Blake 


---
  scripts/checkpatch.pl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5b8735defb..98ed799f29 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -266,7 +266,7 @@ our @typeList = (
qr{target_(?:u)?long},
qr{hwaddr},
qr{xml${Ident}},
-   qr{xendevicemodel_handle},
+   qr{xen\w+_handle},
  );
  
  # This can be modified by sub possible.  Since it can be empty, be careful




--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

On Thu, May 10, 2018 at 1:57 PM, Mirela Simonovic
 wrote:
> Hi,
>
> +Dario
>
> On Wed, May 9, 2018 at 6:32 PM, Julien Grall  wrote:
>>
>>
>> On 09/05/18 16:48, Mirela Simonovic wrote:
>>>
>>> Hi Julien,
>>
>>
>> Hi Mirela,
>>
>>
>>> On Mon, Apr 30, 2018 at 6:09 PM, Julien Grall 
>>> wrote:

 Hi Mirela,


 On 27/04/18 18:12, Mirela Simonovic wrote:
>
>
> On boot, enabling errata workarounds will be triggered by the boot CPU
> from start_xen(). On CPU hotplug (non-boot scenario) this would not be
> done. This patch adds the code required to enable errata workarounds
> for a CPU being hotplugged after the system boots. This is triggered
> using a notifier. If the CPU fails to enable the errata Xen will panic.
> This is done because it is assumed that the CPU which is hotplugged
> after the system/Xen boots, was initially hotplugged during the
> system/Xen boot. Therefore, enabling errata workarounds should never
> fail.
>
> Signed-off-by: Mirela Simonovic 
>
> ---
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>xen/arch/arm/cpuerrata.c | 35
> +++
>xen/arch/arm/cpufeature.c| 23 +++
>xen/include/asm-arm/cpufeature.h |  1 +
>3 files changed, 59 insertions(+)
>
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 1baa20654b..4040f781ec 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -5,6 +5,8 @@
>#include 
>#include 
>#include 
> +#include 
> +#include 
>#include 
>#include 
>#include 
> @@ -349,6 +351,39 @@ void __init enable_errata_workarounds(void)
>enable_cpu_capabilities(arm_errata);
>}
>+static int cpu_errata_callback(
> +struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +switch ( action )
> +{
> +case CPU_STARTING:
> +enable_nonboot_cpu_caps(arm_errata);
> +break;
> +default:
> +break;
> +}
> +
> +return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block cpu_errata_nfb = {
> +.notifier_call = cpu_errata_callback,
> +};
> +
> +static int __init cpu_errata_notifier_init(void)
> +{
> +register_cpu_notifier(_errata_nfb);
> +return 0;
> +}
> +/*
> + * Initialization has to be done at init rather than presmp_init phase
> because
> + * the callback should execute only after the secondary CPUs are
> initially
> + * booted (in hotplug scenarios when the system state is not boot). On
> boot,
> + * the enabling of errata workarounds will be triggered by the boot CPU
> from
> + * start_xen().
> + */
> +__initcall(cpu_errata_notifier_init);
> +
>/*
> * Local variables:
> * mode: C
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 525b45e22f..dd30f0d29c 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -68,6 +68,29 @@ void __init enable_cpu_capabilities(const struct
> arm_cpu_capabilities *caps)
>}
>}
>+/* Run through the enabled capabilities and enable() them on the
> calling CPU */
> +void enable_nonboot_cpu_caps(const struct arm_cpu_capabilities *caps)
> +{
> +ASSERT(system_state != SYS_STATE_boot);
> +
> +for ( ; caps->matches; caps++ )
> +{
> +if ( !cpus_have_cap(caps->capability) )
> +continue;
> +
> +if ( caps->enable )
> +{
> +/*
> + * Since the CPU has enabled errata workarounds on boot, it
> should



 This function is not really about errata, it is about capabilities.
 Errata
 is just a sub-category of them.

>>>
>>> I've fixed the comment, thanks.
>>>
> + * never fail to enable them here.
> + */
> +if ( caps->enable((void *)caps) )
> +panic("CPU%u failed to enable capability %u\n",
> +  smp_processor_id(), caps->capability);



 We should really avoid to use panic(...) if this is something the system
 can
 survive. In that specific case, it would only affect the current CPU. So
 it
 would be better to return an error and let the caller decide what to do.

>>>
>>> I need to emphasize two points:
>>> 1) I don't see how is this different compared to PSCI CPU OFF where we
>>> do panic. Essentially, in both cases the system will not be able to
>>> use that CPU and we 

[Xen-devel] [xen-4.10-testing test] 122643: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122490
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 122490
 build-arm64   4 host-install(4)broken REGR. vs. 122490

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl  12 guest-startfail pass in 122627

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 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-i386-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-amd64-libvirt 13 migrate-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-credit2  13 migrate-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-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-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-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-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-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-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-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

version targeted for testing:
 xen  99e50001bea6f3d777b86bbb9bb41ef66ba47974
baseline version:
 xen  c30ab3d97c8ff0d2ed8948dd013737befc7a2223

Last test of basis   122490  2018-04-28 06:03:56 Z   12 days
Testing same 

Re: [Xen-devel] [SVM] Adding page access bits

[Andrew Cooper]

On 10/05/18 13:59, Alexandru Stefan ISAILA wrote:
> Hello,
>
> We want to add the page access functionality to the SVM code. We have
> been trying to add 4 bits in the pte but all seem to be taken.
>
> Is there a way to accommodate them in the 24 bit flag mask?
>
> I think it can be done by moving the 4 protection key field bits from
> 22:19 to 23:30 so we can have the 19:16 for access. Not sure if bit 23
> is clear
>
> Any thoughts on this matter are appreciated.

The 4 protection key bits bits are architecturally defined.  You cannot
move the bits, or you will break Intel.

That said, I presume you mean the PTEs for the NPT pagetables?

AMD hardware doesn't support PKU yet, and if they were to implement
support, I doubt it would be implemented for the NPT tables.  Therefore,
I think you can just alias the 4 bits.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[George Dunlap]

On 05/10/2018 12:38 PM, George Dunlap wrote:
> On 05/04/2018 09:36 AM, Lars Kurth wrote:
>> The tool covers step 2 of the following workflow
>>
>>   Step 1: git format-patch ... -o  ...
>>   Step 2: ./scripts/add_maintainers.pl -d 
>>   This overwrites  *.patch files in 
>>   Step 3: git send-email -to xen-devel@lists.xenproject.org 
>> /*.patchxm
>>
>> I manually tested all options and the most common combinations
>> on Mac.
>>
>> Changes since v1:
>> - Added RAB (indicated by Juergen on IRC that this is OK)
>> - Remove trailing whitespaces
>> - Renamed --prefix to --reroll-count
>> - Cleaned up short options -v, ... to be in line with git
>> - Added --tags|-t option to add AB, RAB and RB emails to CC list
>> - Added --insert|-i mode to allow for people adding CCs to commit message
>>   instead of the e-mail header (the header is the default)
>> - Moved common code into functions
>> - Added logic, such that the tool only insert's To: and Cc: statements
>>   which were not there before, allowing for running the tool multiple times
>>   on the same 
>>
>> Changes since v2:
>> - Deleted --version and related infrastructure
>> - Added subroutine prototypes
>> - Removed AT and @lists declaration and used \@ in literals
>> - Changed usage message and options based on feedback
>> - Improved error handling
>> - Removed occurances of index() and replaced with regex
>> - Removed non-perl idioms
>> - Moved uniq statements to normalize and added info on what normalize does
>> - Read L: tags from MAINTAINERS file instead of using heuristic
>> - Fixed issues related to metacharacters in getmaintainers()
>> - Allow multiple -a | --arg values (because of this renamed --args)
>> - Identify tags via regex
>> - CC's from tags are only inserted in the mail header, never the body
>> - That is unless the new option --tagscc is used
>> - Added policy processing which includes reworking insert()
>> - Replaced -i|--insert with -p|--inspatch and -c|--inscover now using 
>> policies
>> - Added new policies to cover for all user requests
>> - Rewrote help message to center around usage of policies
>> - Reordered some code (e.g. help string first to make code more easily 
>> readable)
>>
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Julien Grall 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Signed-off-by: Lars Kurth 
>> Release-acked-by: Juergen Gross 
>> ---
>>  scripts/add_maintainers.pl | 512 
>> +
>>  1 file changed, 512 insertions(+)
>>  create mode 100755 scripts/add_maintainers.pl
>>
>> diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
>> new file mode 100755
>> index 00..11ae60d888
>> --- /dev/null
>> +++ b/scripts/add_maintainers.pl
>> @@ -0,0 +1,512 @@
>> +#!/usr/bin/perl -w
>> +# (c) 2018, Lars Kurth 
>> +#
>> +# Add maintainers to patches generated with git format-patch
>> +#
>> +# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
>> +#
>> +# Prerequisites: Execute
>> +#git format-patch ... -o  ...
>> +#
>> +#./scripts/get_maintainer.pl is present in the tree
>> +#
>> +# Licensed under the terms of the GNU GPL License version 2
>> +
>> +use strict;
>> +
>> +use Getopt::Long qw(:config no_auto_abbrev);
>> +use File::Basename;
>> +use List::MoreUtils qw(uniq);
>> +
>> +sub getmaintainers ($$$);
>> +sub gettagsfrompatch ($$$;$);
>> +sub normalize ($$);
>> +sub insert ();
>> +sub hastag ($$);
>> +
>> +# Tool Variables
>> +my $tool = $0;
>> +my $usage = <> +USAGE: $tool [options] (--patchdir | -d) 
>> +
>> +OPTIONS:
>> +
>> +  --reroll-count  | -v 
>> +Choose patch files for specific version. This results into the
>> +following filters on 
>> +0: default - *.patch
>> +>1: v*.patch
>> +  --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
>> +Insert email addresses into *.patch files according to the POLICY
>> +See section POLICY:
>> +  --inscover (top|ccend|none) | -c (top|ccend|none)
>> +Insert email addresses into cover letteraccording to the POLICY
>> +See section PROCESSING POLICY:
>> +  --tags | -t
>> +Read email addresses from tags and add to CC list.
>> +Note that git send-email does not do this. It will add the senders
>> +email adress to the CC list though
>> +  --tagscc
>> +Same as tags, only that in this case CCs extracted from tags
>> +are treated like CCs that have come from the *.patch file
> 
> Not clear on the difference between these.
> 
>> +  --arg  | -a  ...
>> +Arguments passed on to get_maintainer.pl
>> +This option can be used multiple 

[Xen-devel] [SVM] Adding page access bits

[Alexandru Stefan ISAILA]

Hello,

We want to add the page access functionality to the SVM code. We have
been trying to add 4 bits in the pte but all seem to be taken.

Is there a way to accommodate them in the 24 bit flag mask?

I think it can be done by moving the 4 protection key field bits from
22:19 to 23:30 so we can have the 19:16 for access. Not sure if bit 23
is clear

Any thoughts on this matter are appreciated.

Thanks,
Alex


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] xen/arm: Enable errata for secondary CPU on hotplug after the boot

[Mirela Simonovic]

Hi,

+Dario

On Wed, May 9, 2018 at 6:32 PM, Julien Grall  wrote:
>
>
> On 09/05/18 16:48, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi Mirela,
>
>
>> On Mon, Apr 30, 2018 at 6:09 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Mirela,
>>>
>>>
>>> On 27/04/18 18:12, Mirela Simonovic wrote:


 On boot, enabling errata workarounds will be triggered by the boot CPU
 from start_xen(). On CPU hotplug (non-boot scenario) this would not be
 done. This patch adds the code required to enable errata workarounds
 for a CPU being hotplugged after the system boots. This is triggered
 using a notifier. If the CPU fails to enable the errata Xen will panic.
 This is done because it is assumed that the CPU which is hotplugged
 after the system/Xen boots, was initially hotplugged during the
 system/Xen boot. Therefore, enabling errata workarounds should never
 fail.

 Signed-off-by: Mirela Simonovic 

 ---
 CC: Stefano Stabellini 
 CC: Julien Grall 
 ---
xen/arch/arm/cpuerrata.c | 35
 +++
xen/arch/arm/cpufeature.c| 23 +++
xen/include/asm-arm/cpufeature.h |  1 +
3 files changed, 59 insertions(+)

 diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
 index 1baa20654b..4040f781ec 100644
 --- a/xen/arch/arm/cpuerrata.c
 +++ b/xen/arch/arm/cpuerrata.c
 @@ -5,6 +5,8 @@
#include 
#include 
#include 
 +#include 
 +#include 
#include 
#include 
#include 
 @@ -349,6 +351,39 @@ void __init enable_errata_workarounds(void)
enable_cpu_capabilities(arm_errata);
}
+static int cpu_errata_callback(
 +struct notifier_block *nfb, unsigned long action, void *hcpu)
 +{
 +switch ( action )
 +{
 +case CPU_STARTING:
 +enable_nonboot_cpu_caps(arm_errata);
 +break;
 +default:
 +break;
 +}
 +
 +return NOTIFY_DONE;
 +}
 +
 +static struct notifier_block cpu_errata_nfb = {
 +.notifier_call = cpu_errata_callback,
 +};
 +
 +static int __init cpu_errata_notifier_init(void)
 +{
 +register_cpu_notifier(_errata_nfb);
 +return 0;
 +}
 +/*
 + * Initialization has to be done at init rather than presmp_init phase
 because
 + * the callback should execute only after the secondary CPUs are
 initially
 + * booted (in hotplug scenarios when the system state is not boot). On
 boot,
 + * the enabling of errata workarounds will be triggered by the boot CPU
 from
 + * start_xen().
 + */
 +__initcall(cpu_errata_notifier_init);
 +
/*
 * Local variables:
 * mode: C
 diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
 index 525b45e22f..dd30f0d29c 100644
 --- a/xen/arch/arm/cpufeature.c
 +++ b/xen/arch/arm/cpufeature.c
 @@ -68,6 +68,29 @@ void __init enable_cpu_capabilities(const struct
 arm_cpu_capabilities *caps)
}
}
+/* Run through the enabled capabilities and enable() them on the
 calling CPU */
 +void enable_nonboot_cpu_caps(const struct arm_cpu_capabilities *caps)
 +{
 +ASSERT(system_state != SYS_STATE_boot);
 +
 +for ( ; caps->matches; caps++ )
 +{
 +if ( !cpus_have_cap(caps->capability) )
 +continue;
 +
 +if ( caps->enable )
 +{
 +/*
 + * Since the CPU has enabled errata workarounds on boot, it
 should
>>>
>>>
>>>
>>> This function is not really about errata, it is about capabilities.
>>> Errata
>>> is just a sub-category of them.
>>>
>>
>> I've fixed the comment, thanks.
>>
 + * never fail to enable them here.
 + */
 +if ( caps->enable((void *)caps) )
 +panic("CPU%u failed to enable capability %u\n",
 +  smp_processor_id(), caps->capability);
>>>
>>>
>>>
>>> We should really avoid to use panic(...) if this is something the system
>>> can
>>> survive. In that specific case, it would only affect the current CPU. So
>>> it
>>> would be better to return an error and let the caller decide what to do.
>>>
>>
>> I need to emphasize two points:
>> 1) I don't see how is this different compared to PSCI CPU OFF where we
>> do panic. Essentially, in both cases the system will not be able to
>> use that CPU and we already agreed that is a good reason to panic.
>
>
> You can't compare PSCI CPU off and the enable callback failing. The *only*
> reason PSCI CPU off can fail is because the Trusted OS is resident on that
> CPU. If that ever happen it is a 

Re: [Xen-devel] [PATCH v2 1/3] xen/pvh: enable and set default MTRR type

[Wei Liu]

On Wed, May 09, 2018 at 04:11:39PM +0100, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
> > On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
> > > On 09/05/18 11:21, Roger Pau Monne wrote:
> > > I'm not sure that setting the default MTRR type is going to be a
> > > clever idea in hindsight when we come to doing PCI Passthrough support.
> > 
> > Setting the default type to WB is also set by hvmloader, it's just
> > that hvmloader also sets some of the fixed and variable ranges to UC
> > in order to cover the iomem areas.
> > 
> > The expectations when doing pci-passthrough is that the guest will
> > always use paging and PAT in order to set the appropriate cache
> > attributes, or else the guest itself will have to program the UC MTRR
> > ranges, I admit that's not very nice however.
> > 
> > What about enabling the default MTRR type and setting it to WB in the
> > toolstack for PVH? IMO doing it Xen itself would be wrong.
> 
> I have the following patch to set the default MTRR type, but I think
> if we go down this road then we will also have to set UC MTRRs for
> MMIO areas, which again seems fine to me.
> 

Can you please document the default type(s) to pvh.markdown once
the issue is resolved?

Wei.

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

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[George Dunlap]

On 05/10/2018 12:38 PM, George Dunlap wrote:

>   --patchcc (top|commit|comment|none) | -p (top|commit|comment|none)
> 
> Insert CC lines into *.patch files in the specified location.
> See LOCATIONS for a definition of the various locations.
> 
> The default is `top`.
> 
>   --covercc (top|end|none) | -c (top|end|none)

s/top/header/g; for these

 -George

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

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[George Dunlap]

On 05/04/2018 09:36 AM, Lars Kurth wrote:
> The tool covers step 2 of the following workflow
> 
>   Step 1: git format-patch ... -o  ...
>   Step 2: ./scripts/add_maintainers.pl -d 
>   This overwrites  *.patch files in 
>   Step 3: git send-email -to xen-devel@lists.xenproject.org 
> /*.patchxm
> 
> I manually tested all options and the most common combinations
> on Mac.
> 
> Changes since v1:
> - Added RAB (indicated by Juergen on IRC that this is OK)
> - Remove trailing whitespaces
> - Renamed --prefix to --reroll-count
> - Cleaned up short options -v, ... to be in line with git
> - Added --tags|-t option to add AB, RAB and RB emails to CC list
> - Added --insert|-i mode to allow for people adding CCs to commit message
>   instead of the e-mail header (the header is the default)
> - Moved common code into functions
> - Added logic, such that the tool only insert's To: and Cc: statements
>   which were not there before, allowing for running the tool multiple times
>   on the same 
> 
> Changes since v2:
> - Deleted --version and related infrastructure
> - Added subroutine prototypes
> - Removed AT and @lists declaration and used \@ in literals
> - Changed usage message and options based on feedback
> - Improved error handling
> - Removed occurances of index() and replaced with regex
> - Removed non-perl idioms
> - Moved uniq statements to normalize and added info on what normalize does
> - Read L: tags from MAINTAINERS file instead of using heuristic
> - Fixed issues related to metacharacters in getmaintainers()
> - Allow multiple -a | --arg values (because of this renamed --args)
> - Identify tags via regex
> - CC's from tags are only inserted in the mail header, never the body
> - That is unless the new option --tagscc is used
> - Added policy processing which includes reworking insert()
> - Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies
> - Added new policies to cover for all user requests
> - Rewrote help message to center around usage of policies
> - Reordered some code (e.g. help string first to make code more easily 
> readable)
> 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Signed-off-by: Lars Kurth 
> Release-acked-by: Juergen Gross 
> ---
>  scripts/add_maintainers.pl | 512 
> +
>  1 file changed, 512 insertions(+)
>  create mode 100755 scripts/add_maintainers.pl
> 
> diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
> new file mode 100755
> index 00..11ae60d888
> --- /dev/null
> +++ b/scripts/add_maintainers.pl
> @@ -0,0 +1,512 @@
> +#!/usr/bin/perl -w
> +# (c) 2018, Lars Kurth 
> +#
> +# Add maintainers to patches generated with git format-patch
> +#
> +# Usage: perl scripts/add_maintainers.pl [OPTIONS] -patchdir 
> +#
> +# Prerequisites: Execute
> +#git format-patch ... -o  ...
> +#
> +#./scripts/get_maintainer.pl is present in the tree
> +#
> +# Licensed under the terms of the GNU GPL License version 2
> +
> +use strict;
> +
> +use Getopt::Long qw(:config no_auto_abbrev);
> +use File::Basename;
> +use List::MoreUtils qw(uniq);
> +
> +sub getmaintainers ($$$);
> +sub gettagsfrompatch ($$$;$);
> +sub normalize ($$);
> +sub insert ();
> +sub hastag ($$);
> +
> +# Tool Variables
> +my $tool = $0;
> +my $usage = < +USAGE: $tool [options] (--patchdir | -d) 
> +
> +OPTIONS:
> +
> +  --reroll-count  | -v 
> +Choose patch files for specific version. This results into the
> +following filters on 
> +0: default - *.patch
> +>1: v*.patch
> +  --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none)
> +Insert email addresses into *.patch files according to the POLICY
> +See section POLICY:
> +  --inscover (top|ccend|none) | -c (top|ccend|none)
> +Insert email addresses into cover letteraccording to the POLICY
> +See section PROCESSING POLICY:
> +  --tags | -t
> +Read email addresses from tags and add to CC list.
> +Note that git send-email does not do this. It will add the senders
> +email adress to the CC list though
> +  --tagscc
> +Same as tags, only that in this case CCs extracted from tags
> +are treated like CCs that have come from the *.patch file

Not clear on the difference between these.

> +  --arg  | -a  ...
> +Arguments passed on to get_maintainer.pl
> +This option can be used multiple times, e.g. -a  -a  ...
> +  --verbose
> +Show more output
> +  --help | -h
> +Show this help information
> +
> +PROCESSING POLICY:

Why is this called 'policy'?  This 

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

[Wei Liu]

On Wed, May 09, 2018 at 05:07:12PM +0100, Roger Pau Monne wrote:
> This prevents page-shattering, by being able to populate the RAM
> regions below 4GB using 1GB pages, provided the guest memory size is
> set to a multiple of a GB.
> 
> Note that there are some special and ACPI pages in the MMIO hole that
> will be populated using smaller order pages, but those shouldn't be
> accessed as often as RAM regions.
> 
> Signed-off-by: Roger Pau Monné 

This idea sounds fine to me.

Wei.

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

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Anthony PERARD]

On Tue, May 08, 2018 at 01:31:43PM +0200, Olaf Hering wrote:
> It is unclear why that was never noticed in xen-4.10, qemu-2.9 did not have 
> that bug.
> Also, if a KVM or Xen guest is migrated should make zero difference for the 
> qcow2 driver...

Hi Olaf,

I did try to fix a migration related issue that has to do with a new
lock placed by qemu. But if the issue your having is actually fixed.

The lock as been introduced in QEMU 2.10, but the was not working well
with Xen, so for Xen 4.10, I've apply to qemu-xen-4.10:
migration, xen: Fix block image lock issue on live migration
a4166a0a50dda967f30c9d85fa8aa2ea2539798e

I did fix the bug in QEMU 2.11 (5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad)
so Xen 4.11 does include it it the qemu-xen tree.

There is one last commit for libxl:
libxl_qmp: Tell QEMU about live migration or snapshot
db0c7dde021c29c2ae0d847d70fb7b59e02ea522

I'm not sure if that information is going to help, but that what I have
for now about the lock of block images.



-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

[Roger Pau Monné]

On Thu, May 10, 2018 at 10:43:26AM +0100, George Dunlap wrote:
> On Wed, May 9, 2018 at 5:07 PM, Roger Pau Monne  wrote:
> > This prevents page-shattering, by being able to populate the RAM
> > regions below 4GB using 1GB pages, provided the guest memory size is
> > set to a multiple of a GB.
> >
> > Note that there are some special and ACPI pages in the MMIO hole that
> > will be populated using smaller order pages, but those shouldn't be
> > accessed as often as RAM regions.
> 
> Is it possible to run PVH in pure 32-bit mode (as opposed to 32-bit
> PAE)?  If so, such guests would be limited to 3GiB of total memory
> (instead of 4GiB).

Yes, that's correct. PVH guests are not limited to any mode, you could
even run them in protected or real mode.

> But I suppose there's no particular reason to run PVH in pure 32-bit
> mode instead of 32-bit PAE.  (I don't *think* TLB misses are slower on
> 3-level paging than 2-level paging, because the L3 entries are
> essentially loaded on CR3 switch.)
> 
> So at the moment this seems OK to me.  If someone decides they want to
> run PVH 2-level paging with more than 3GiB of RAM, we can easily add
> an option to turn it on.

That's my opinion. HVM guests already have a mmio_hole option, it
would be almost trivial to make that option also available to PVH if
there's a need for it.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

[Andrew Cooper]

On 10/05/18 10:26, Kang, Luwei wrote:
> Here is a patch-series which adding Processor Trace enabling in XEN 
> guest. You can get It's software developer manuals from:
> https://software.intel.com/sites/default/files/managed/c5/15/archite
> ct ure-instruction-set-extensions-programming-reference.pdf
> In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
>
> Introduction:
> Intel Processor Trace (Intel PT) is an extension of Intel
> Architecture that captures information about software execution
> using
 dedicated hardware facilities that cause only minimal performance
 perturbation to the software being traced. Details on the Intel PT 
 infrastructure and trace capabilities can be found in the Intel 64
>> and IA-32 Architectures Software Developer’s Manual, Volume 3C.
> The suite of architecture changes serve to simplify the process of
> virtualizing Intel PT for use by a guest software. There are two
 primary elements to this new architecture support for VMX support 
 improvements made for Intel PT.
> 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
>   — This serves to speed and simplify the process of disabling trace on 
> VM exit, and restoring it on VM entry.
> 2. Enabling use of EPT to redirect PT output.
>   — This enables the VMM to elect to virtualize the PT output buffer
> using EPT. In this mode, the CPU will treat PT output
 addresses as Guest Physical Addresses (GPAs) and translate them using
 EPT. This means that Intel PT output reads (of the ToPA
 table) and writes (of trace output) can cause EPT violations, and other 
 output events.
 A high level question, SDM vol 3 "Emulation of Intel PT Traced State"
 says:

 "If a VMM emulates an element of processor state by taking a VM exit
 on reads and/or writes to that piece of state, and the state element
 impacts Intel PT packet generation or values, it may be incumbent upon the 
 VMM to insert or modify the output trace data."

 The immediately follows that paragraph is an example of CR3 causing
 vmexit which leads to missing packet. IIRC Xen does that, however the code 
 as is doesn't seem to handle that at all.
>>> Hi Wei,
>>> Intel PT can be exposed to guest only when EPT is enabled. In that 
>>> case, CPU_BASED_CR3_LOAD_EXITING and
>> CPU_BASED_CR3_STORE_EXITING would be clear, so "MOV CR3 " will not cause a 
>> vm-exit. It looks like don't need emulate the
>> missing PIP by writing it into the guest output buffer.
>>
>> With introspection, the guest mov to cr3 instruction might be on a page 
>> protected with NX at the EPT level, at which point it traps
>> for inspection and will be completed with emulation, to avoid the overhead 
>> of changing EPT permissions, singlestepping the guest,
>> then reinstating the NX protection.
>>
>> Basically, any and all actions could end up requiring emulation, based on 
>> the safety decisions of the introspection logic.
> Hi Andrew, 
>  As you mentioned in previous mail and emphasized in community call. Any 
> instruction might be on a page protected with NX at the EPT level. So it 
> looks like that almost all the Trace packet need to be emulated. For example, 
> TNT(taken/not-taken) might be emulate for branch instruction, TIP(target IP) 
> might be emulate for branch, interrupt, exception and so on. Is that right?

Yes.  Then again, this information is readily available from the
emulator.  What we probably need (although I've not put much thought
into this) is to accumulate a list of trace events during emulation,
then insert them into the trace log only when we retire the instruction.

~Andrew

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

Re: [Xen-devel] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

[George Dunlap]

On Wed, May 9, 2018 at 5:07 PM, Roger Pau Monne  wrote:
> This prevents page-shattering, by being able to populate the RAM
> regions below 4GB using 1GB pages, provided the guest memory size is
> set to a multiple of a GB.
>
> Note that there are some special and ACPI pages in the MMIO hole that
> will be populated using smaller order pages, but those shouldn't be
> accessed as often as RAM regions.

Is it possible to run PVH in pure 32-bit mode (as opposed to 32-bit
PAE)?  If so, such guests would be limited to 3GiB of total memory
(instead of 4GiB).

But I suppose there's no particular reason to run PVH in pure 32-bit
mode instead of 32-bit PAE.  (I don't *think* TLB misses are slower on
3-level paging than 2-level paging, because the L3 entries are
essentially loaded on CR3 switch.)

So at the moment this seems OK to me.  If someone decides they want to
run PVH 2-level paging with more than 3GiB of RAM, we can easily add
an option to turn it on.

(Haven't reviewed the code.)

 -George

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

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

[Kang, Luwei]

> >>> Here is a patch-series which adding Processor Trace enabling in XEN 
> >>> guest. You can get It's software developer manuals from:
> >>> https://software.intel.com/sites/default/files/managed/c5/15/archite
> >>> ct ure-instruction-set-extensions-programming-reference.pdf
> >>> In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
> >>>
> >>> Introduction:
> >>> Intel Processor Trace (Intel PT) is an extension of Intel
> >>> Architecture that captures information about software execution
> >>> using
> >> dedicated hardware facilities that cause only minimal performance
> >> perturbation to the software being traced. Details on the Intel PT 
> >> infrastructure and trace capabilities can be found in the Intel 64
> and IA-32 Architectures Software Developer’s Manual, Volume 3C.
> >>> The suite of architecture changes serve to simplify the process of
> >>> virtualizing Intel PT for use by a guest software. There are two
> >> primary elements to this new architecture support for VMX support 
> >> improvements made for Intel PT.
> >>> 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
> >>>   — This serves to speed and simplify the process of disabling trace on 
> >>> VM exit, and restoring it on VM entry.
> >>> 2. Enabling use of EPT to redirect PT output.
> >>>   — This enables the VMM to elect to virtualize the PT output buffer
> >>> using EPT. In this mode, the CPU will treat PT output
> >> addresses as Guest Physical Addresses (GPAs) and translate them using
> >> EPT. This means that Intel PT output reads (of the ToPA
> >> table) and writes (of trace output) can cause EPT violations, and other 
> >> output events.
> >> A high level question, SDM vol 3 "Emulation of Intel PT Traced State"
> >> says:
> >>
> >> "If a VMM emulates an element of processor state by taking a VM exit
> >> on reads and/or writes to that piece of state, and the state element
> >> impacts Intel PT packet generation or values, it may be incumbent upon the 
> >> VMM to insert or modify the output trace data."
> >>
> >> The immediately follows that paragraph is an example of CR3 causing
> >> vmexit which leads to missing packet. IIRC Xen does that, however the code 
> >> as is doesn't seem to handle that at all.
> > Hi Wei,
> > Intel PT can be exposed to guest only when EPT is enabled. In that 
> > case, CPU_BASED_CR3_LOAD_EXITING and
> CPU_BASED_CR3_STORE_EXITING would be clear, so "MOV CR3 " will not cause a 
> vm-exit. It looks like don't need emulate the
> missing PIP by writing it into the guest output buffer.
> 
> With introspection, the guest mov to cr3 instruction might be on a page 
> protected with NX at the EPT level, at which point it traps
> for inspection and will be completed with emulation, to avoid the overhead of 
> changing EPT permissions, singlestepping the guest,
> then reinstating the NX protection.
> 
> Basically, any and all actions could end up requiring emulation, based on the 
> safety decisions of the introspection logic.

Hi Andrew, 
 As you mentioned in previous mail and emphasized in community call. Any 
instruction might be on a page protected with NX at the EPT level. So it looks 
like that almost all the Trace packet need to be emulated. For example, 
TNT(taken/not-taken) might be emulate for branch instruction, TIP(target IP) 
might be emulate for branch, interrupt, exception and so on. Is that right?

Thanks,
Luwei Kang

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

[Xen-devel] [PATCH v2 3/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

[Paul Durrant]

Xen 4.11 has a new API to directly map guest resources. Among the resources
that can be mapped using this API are ioreq pages.

This patch modifies QEMU to attempt to use the new API should it exist,
falling back to the previous mechanism if it is unavailable.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 configure   |  5 
 hw/i386/xen/trace-events|  1 +
 hw/i386/xen/xen-hvm.c   | 68 +++--
 include/hw/xen/xen_common.h | 14 ++
 4 files changed, 73 insertions(+), 15 deletions(-)

diff --git a/configure b/configure
index 1443422e83..0f9c2f000e 100755
--- a/configure
+++ b/configure
@@ -2229,12 +2229,17 @@ EOF
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
 #define __XEN_TOOLS__
 #include 
+#include 
 int main(void) {
   xendevicemodel_handle *xd;
+  xenforeignmemory_handle *xfmem;
 
   xd = xendevicemodel_open(0, 0);
   xendevicemodel_pin_memory_cacheattr(xd, 0, 0, 0, 0);
 
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map_resource(xfmem, 0, 0, 0, 0, 0, NULL, 0, 0);
+
   return 0;
 }
 EOF
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 8dab7bcfe0..38616b698f 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -15,6 +15,7 @@ cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t 
data_is_ptr, uint64
 cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) 
"I/O=%p pio read reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
 cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t 
size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
 cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy 
dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
 
 # xen-mapcache.c
 xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 6ffa3c22cc..664cc52532 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1239,13 +1239,41 @@ static void xen_wakeup_notifier(Notifier *notifier, 
void *data)
 
 static int xen_map_ioreq_server(XenIOState *state)
 {
+void *addr = NULL;
+xenforeignmemory_resource_handle *fres;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
 int rc;
 
+/*
+ * Attempt to map using the resource API and fall back to normal
+ * foreign mapping if this is not supported.
+ */
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
+fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
+ XENMEM_resource_ioreq_server,
+ state->ioservid, 0, 2,
+ ,
+ PROT_READ | PROT_WRITE, 0);
+if (fres != NULL) {
+trace_xen_map_resource_ioreq(state->ioservid, addr);
+state->buffered_io_page = addr;
+state->shared_page = addr + TARGET_PAGE_SIZE;
+} else {
+error_report("failed to map ioreq server resources: error %d 
handle=%p",
+ errno, xen_xc);
+if (errno != EOPNOTSUPP) {
+return -1;
+}
+}
+
 rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
-   _pfn, _pfn,
+   (state->shared_page == NULL) ?
+   _pfn : NULL,
+   (state->buffered_io_page == NULL) ?
+   _pfn : NULL,
_evtchn);
 if (rc < 0) {
 error_report("failed to get ioreq server info: error %d handle=%p",
@@ -1253,27 +1281,37 @@ static int xen_map_ioreq_server(XenIOState *state)
 return rc;
 }
 
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
-  PROT_READ | PROT_WRITE,
-  1, _pfn, NULL);
 if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
-return -1;
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+  PROT_READ | PROT_WRITE,
+  1, _pfn, NULL);

[Xen-devel] [PATCH v2 1/3] xen-hvm: create separate function for ioreq server initialization

[Paul Durrant]

The code is sufficiently substantial that it improves code readability
to put it in a new function called by xen_hvm_init() rather than having
it inline.

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Anthony Perard 
---
 hw/i386/xen/xen-hvm.c | 76 +++
 1 file changed, 46 insertions(+), 30 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index caa563be3d..6ffa3c22cc 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -95,7 +95,8 @@ typedef struct XenIOState {
 CPUState **cpu_by_vcpu_id;
 /* the evtchn port for polling the notification, */
 evtchn_port_t *ioreq_local_port;
-/* evtchn local port for buffered io */
+/* evtchn remote and local ports for buffered io */
+evtchn_port_t bufioreq_remote_port;
 evtchn_port_t bufioreq_local_port;
 /* the evtchn fd for polling */
 xenevtchn_handle *xce_handle;
@@ -1236,12 +1237,52 @@ static void xen_wakeup_notifier(Notifier *notifier, 
void *data)
 xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
 }
 
-void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+static int xen_map_ioreq_server(XenIOState *state)
 {
-int i, rc;
 xen_pfn_t ioreq_pfn;
 xen_pfn_t bufioreq_pfn;
 evtchn_port_t bufioreq_evtchn;
+int rc;
+
+rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
+   _pfn, _pfn,
+   _evtchn);
+if (rc < 0) {
+error_report("failed to get ioreq server info: error %d handle=%p",
+ errno, xen_xc);
+return rc;
+}
+
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
+DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+  PROT_READ | PROT_WRITE,
+  1, _pfn, NULL);
+if (state->shared_page == NULL) {
+error_report("map shared IO page returned error %d handle=%p",
+ errno, xen_xc);
+return -1;
+}
+
+state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
+   PROT_READ | PROT_WRITE,
+   1, _pfn, NULL);
+if (state->buffered_io_page == NULL) {
+error_report("map buffered IO page returned error %d", errno);
+return -1;
+}
+
+state->bufioreq_remote_port = bufioreq_evtchn;
+
+return 0;
+}
+
+void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
+{
+int i, rc;
+xen_pfn_t ioreq_pfn;
 XenIOState *state;
 
 state = g_malloc0(sizeof (XenIOState));
@@ -1269,25 +1310,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 state->wakeup.notify = xen_wakeup_notifier;
 qemu_register_wakeup_notifier(>wakeup);
 
-rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
-   _pfn, _pfn,
-   _evtchn);
+rc = xen_map_ioreq_server(state);
 if (rc < 0) {
-error_report("failed to get ioreq server info: error %d handle=%p",
- errno, xen_xc);
-goto err;
-}
-
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
-  PROT_READ|PROT_WRITE,
-  1, _pfn, NULL);
-if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
 goto err;
 }
 
@@ -1308,14 +1332,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 goto err;
 }
 
-state->buffered_io_page = xenforeignmemory_map(xen_fmem, xen_domid,
-   PROT_READ|PROT_WRITE,
-   1, _pfn, NULL);
-if (state->buffered_io_page == NULL) {
-error_report("map buffered IO page returned error %d", errno);
-goto err;
-}
-
 /* Note: cpus is empty at this point in init */
 state->cpu_by_vcpu_id = g_malloc0(max_cpus * sizeof(CPUState *));
 
@@ -1340,7 +1356,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 }
 
 rc = xenevtchn_bind_interdomain(state->xce_handle, xen_domid,
-bufioreq_evtchn);
+state->bufioreq_remote_port);
 if (rc == -1) {
 error_report("buffered evtchn bind error %d", 

[Xen-devel] [PATCH v2 2/3] checkpatch: generalize xen handle matching in the list of types

[Paul Durrant]

All the xen stable APIs define handle types of the form:

_handle

and some define additional handle types of the form:

__handle

Examples of these are xenforeignmemory_handle and
xenforeignmemory_resource_handle.

Both of these types will be misparsed by checkpatch if they appear as the
first token in a line since, as types defined by an external library, they
do not conform to the QEMU CODING_STYLE, which suggests CamelCase.

A previous patch (5ac067a24a8) added xendevicemodel_handle to the list
of types. This patch changes that to xen\w+_handle such that it will
match all Xen stable API handles of the forms detailed above.

Signed-off-by: Paul Durrant 
---
Cc: Eric Blake 
Cc: Paolo Bonzini 
Cc: Daniel P. Berrange 

v2:
 - New in this version
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 5b8735defb..98ed799f29 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -266,7 +266,7 @@ our @typeList = (
qr{target_(?:u)?long},
qr{hwaddr},
qr{xml${Ident}},
-   qr{xendevicemodel_handle},
+   qr{xen\w+_handle},
 );
 
 # This can be modified by sub possible.  Since it can be empty, be careful
-- 
2.11.0


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

[Xen-devel] [PATCH v2 0/2] xen-hvm: use new resource mapping API

[Paul Durrant]

This series modifies QEMU to use the new guest resource mapping API
(available in Xen 4.11+) to map ioreq pages.

v2:
 - Add a patch to checkpatch to avoid misparsing of Xen stable API handles

Paul Durrant (3):
  xen-hvm: create separate function for ioreq server initialization
  checkpatch: generalize xen handle matching in the list of types
  xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages

 configure   |   5 ++
 hw/i386/xen/trace-events|   1 +
 hw/i386/xen/xen-hvm.c   | 114 
 include/hw/xen/xen_common.h |  14 ++
 scripts/checkpatch.pl   |   2 +-
 5 files changed, 105 insertions(+), 31 deletions(-)
---
Cc: Anthony Perard 
Cc: Daniel P. Berrange 
Cc: Eric Blake 
Cc: Paolo Bonzini 
Cc: Stefano Stabellini 

-- 
2.11.0


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

[Xen-devel] [PATCH] vhpet: check that the set interrupt route is valid

[Roger Pau Monne]

The value written by the guest must be valid according to the mask
provided in the interrupt routing capabilities register. If the
interrupt is not valid set it to the first valid IRQ in the
capabilities field if the timer is enabled, else just clear the field.

Also refuse to start any timer that has an invalid interrupt route.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hpet.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 28377091ca..8772802524 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -73,6 +73,9 @@
 ((timer_config(h, n) & HPET_TN_INT_ROUTE_CAP_MASK) \
 >> HPET_TN_INT_ROUTE_CAP_SHIFT)
 
+#define timer_int_valid(h, n) \
+((1u << timer_int_route(h, n)) & timer_int_route_cap(h, n))
+
 static inline uint64_t hpet_read_maincounter(HPETState *h, uint64_t guest_time)
 {
 ASSERT(rw_is_locked(>lock));
@@ -244,6 +247,12 @@ static void hpet_set_timer(HPETState *h, unsigned int tn,
 if ( !timer_enabled(h, tn) )
 return;
 
+if ( !timer_int_valid(h, tn) )
+{
+ASSERT_UNREACHABLE();
+return;
+}
+
 tn_cmp   = hpet_get_comparator(h, tn, guest_time);
 cur_tick = hpet_read_maincounter(h, guest_time);
 if ( timer_is_32bit(h, tn) )
@@ -304,6 +313,30 @@ static inline uint64_t hpet_fixup_reg(
 return new;
 }
 
+static void timer_sanitize_int(HPETState *h, unsigned int tn)
+{
+unsigned int irq;
+
+if ( timer_int_valid(h, tn) )
+return;
+
+h->hpet.timers[tn].config &= ~HPET_TN_ROUTE;
+if ( !timer_enabled(h, tn) )
+return;
+
+/*
+ * If the requested interrupt is not valid and the timer is
+ * enabled pick the first irq.
+ */
+irq = ffs(timer_int_route_cap(h, tn));
+if ( !irq )
+{
+ASSERT_UNREACHABLE();
+return;
+}
+h->hpet.timers[tn].config |= (irq - 1) << HPET_TN_ROUTE_SHIFT;
+}
+
 static int hpet_write(
 struct vcpu *v, unsigned long addr,
 unsigned int length, unsigned long val)
@@ -386,6 +419,8 @@ static int hpet_write(
 
 h->hpet.timers[tn].config = hpet_fixup_reg(new_val, old_val, 0x3f4e);
 
+timer_sanitize_int(h, tn);
+
 if ( timer_level(h, tn) )
 {
 gdprintk(XENLOG_ERR,
@@ -621,6 +656,7 @@ static int hpet_load(struct domain *d, hvm_domain_context_t 
*h)
 if ( timer_is_32bit(hp, i) )
 cmp = (uint32_t)cmp;
 hp->hpet.timers[i].cmp = cmp;
+timer_sanitize_int(hp, i);
 }
 #undef C
 
-- 
2.17.0


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

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

[Kang, Luwei]

> >>> On 04.05.18 at 05:53,  wrote:
> >> >  Thanks for your clarification. Please correct me if I have
> >> > something wrong. Guest may execute an instruction and this
> >> > instruction may produce an PT packet save in PT output buffer. An
> >> > EPT violation will be generated if the address of this PT buffer
> >> > don't have EPT page table mapping, but this EPT violations
> >> > shouldn't be handled by
> >> > x86_emulate() because it no relate with the execute of this instruction.
> >>
> >> Plus - and that's very important - the EPT violation may be reported
> >> on some
> > later insn.
> >
> > You mean the "later instruction" is some new instruction in future hardware?
> 
> No, I mean an instruction following later in the instruction stream.
> 
> >> >  In that case, can we build the EPT map when set the output
> >> > buffer address (IA32_RTIT_OUTPUT_BASE) and crash the guest if still
> >> > happened EPT violation with Intel PT output buffer read/write exit
> >> > qualification. Or add an exit qualification check before instruction 
> >> > emulation?
> >>
> >> Imo you should add an exit qualification check in any case. Depending
> >> what
> > else you do, finding the new bit set may imply crashing
> >> the domain or doing something more sophisticated.
> >
> > Do you mean add this check at the beginning of any specific "exit_reason"
> > handler in vmx_vmexit_handler() function?
> 
> That depends. Surely not for every exit reason, but only those for which this 
> new bit is valid (iirc exit qualifications differ per exit
> reason anyway, so you can't unilaterally check the same bit everywhere). And 
> even for those where the bit is valid, I'm not sure you
> can decide in the exit handler alone what to do if the bit is set. It may be 
> necessary to propagate the flag down the call tree.
> 
> > Another question is where to build this EPT mapping? Setting
> > IA32_RTIT_OUTPUT_BASE or handled by EPT violation?
> 
> I have no idea - that's more a question for you to answer yourself.
> 

I make a draft patch for VM exit caused by Intel PT output (comments as 
annotation). It looks have little thing to deal with.
There have four case which may cause VM-exit by PT output (spec 5.2.2.1).
1. EPT violations. This because there don't have EPT mapping from GPA to HPA, I 
think this can be handled as usual. About MMIO, I think maybe we can make guest 
OS crash.
2. EPT misconfigurations. We may misconfigure EPT table for log the dirty page 
and MMIO access (Please correct me if have something wrong). I can't find there 
need to have some special need to be handled.
3. PML log-full. PT output may cause vm-exit for PML  log-full when trace 
record to a new page. But it looks don't need additional handle as well.
4. APIC access. Currently, I have no idea about how this relate with PT buffer 
write. When PT buffer is full, an PMI interrupt would be injected to this VM, 
but still have no direct relationship.

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983c..fbf272e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1873,6 +1873,18 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
  (npfec.write_access &&
   (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
+/*
+ * Don't need emulate and make guest crash when write to
+ * mmio address or a ram address without write permission.
+ * In fact, output buffer can set to be MMIO address (35.2.6.1),
+ * it need the support of a hardware PCI card which use for
+ * collect trace information. I am afraid it initialized to
+ * a valid general MMIO address which is used by a pass through
+ * device.
+ */
+if ( npfec.pt_output )
+goto out_put_gfn;
+
 if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
 hvm_inject_hw_exception(TRAP_gp_fault, 0);
 rc = 1;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 021cf33..ba4f979 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3249,6 +3249,7 @@ static void ept_handle_violation(ept_qual_t q, paddr_t 
gpa)
 .write_access = q.write,
 .insn_fetch = q.fetch,
 .present = q.eff_read || q.eff_write || q.eff_exec,
+.pt_output = q.pt_output,
 };

 if ( tb_init_done )
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 89619e4..70b6c5f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -620,11 +620,13 @@ void vmx_pi_hooks_deassign(struct domain *d);
 typedef union ept_qual {
 unsigned long raw;
 struct {
-bool read:1, write:1, fetch:1,
+unsigned long read:1, write:1, fetch:1,
 eff_read:1, eff_write:1, eff_exec:1, /* eff_user_exec */:1,
 gla_valid:1,
-gla_fault:1; /* Valid 

[Xen-devel] [distros-debian-wheezy test] 74702: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   74664

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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] [PATCH RFC] libxl: set 1GB MMIO hole for PVH

[Roger Pau Monné]

On Wed, May 09, 2018 at 06:12:28PM +0200, Juergen Gross wrote:
> On 09/05/18 18:07, Roger Pau Monne wrote:
> > This prevents page-shattering, by being able to populate the RAM
> > regions below 4GB using 1GB pages, provided the guest memory size is
> > set to a multiple of a GB.
> > 
> > Note that there are some special and ACPI pages in the MMIO hole that
> > will be populated using smaller order pages, but those shouldn't be
> > accessed as often as RAM regions.
> 
> Would it be possible somehow to put a potential firmware into that
> 1GB region, too, if it needs any memory in high memory? Seabios e.g.
> is taking the last RAM page of the guest for its hypercall page, which
> will again shatter GB mappings.

I know this comment is related to HVM guests, but I'm not sure I see
how setting the hypercall page shatters GB mappings. Setting the
hypercall page doesn't involve changing any p2m mappings, but just
filling a guest RAM page with some data.

Roger.

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

Re: [Xen-devel] [Qemu-devel] [PATCH 0/2] xen-hvm: use new resource mapping API

[Paul Durrant]

> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: 09 May 2018 18:26
> To: Paul Durrant ; qemu-de...@nongnu.org
> Cc: xen-devel@lists.xenproject.org; f...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH 0/2] xen-hvm: use new resource mapping
> API
> 
> On 05/09/2018 11:05 AM, Paul Durrant wrote:
> 
> >> xenforeignmemory_map_resource() to map ioreq pages...
> >> ERROR: spaces required around that '*' (ctx:WxV)
> >> #164: FILE: include/hw/xen/xen_common.h:128:
> >> +xenforeignmemory_handle *fmem, domid_t domid, unsigned int
> type,
> >>   ^
> >>
> >> total: 1 errors, 0 warnings, 138 lines checked
> >>
> >> Your patch has style problems, please review.  If any of these errors
> >> are false positives report them to the maintainer, see
> >> CHECKPATCH in MAINTAINERS.
> >
> > This style warning appears to be spurious.
> 
> Yep, and it's because xenforeignmemory_handle doesn't follow our usual
> conventions for a type name.  See commit 5ac067a if you want to add it
> to the list of whitelisted exception type names, to silence messages
> like this.

Thanks Eric. I'll send a v2 series with a suitable additional patch.

  Cheers,

Paul

> 
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH -resend 01/27] linkage: new macros for assembler symbols

[Jiri Slaby]

Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.

So introduce macros with clear use to annotate assembly as follows:

a) Support macros for the ones below
   SYM_T_FUNC -- type used by assembler to mark functions
   SYM_T_OBJECT -- type used by assembler to mark data
   SYM_T_NONE -- type used by assembler to mark entries of unknown type

   They are defined as STT_FUNC, STT_OBJECT, and STT_NOTYPE
   respectively. According to the gas manual, this is the most portable
   way. I am not sure about other assemblers, so we can switch this back
   to %function and %object if this turns into a problem. Architectures
   can also override them by something like ", @function" if they need.

   SYM_A_ALIGN, SYM_A_NONE -- align the symbol?
   SYM_L_GLOBAL, SYM_L_WEAK, SYM_L_LOCAL -- linkage of symbols

b) Mostly internal annotations, used by the ones below
   SYM_ENTRY -- use only if you have to (for non-paired symbols)
   SYM_START -- use only if you have to (for paired symbols)
   SYM_END -- use only if you have to (for paired symbols)

c) Annotations for code
   SYM_FUNC_START_LOCAL_ALIAS -- use where there are two local names for
one function
   SYM_FUNC_START_ALIAS -- use where there are two global names for one
function
   SYM_FUNC_END_ALIAS -- the end of LOCAL_ALIASed or ALIASed function

   SYM_FUNC_START -- use for global functions
   SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment
   SYM_FUNC_START_LOCAL -- use for local functions
   SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o
alignment
   SYM_FUNC_START_WEAK -- use for weak functions
   SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment
   SYM_FUNC_END -- the end of SYM_FUNC_START_LOCAL, SYM_FUNC_START,
SYM_FUNC_START_WEAK, ...

   SYM_FUNC_INNER_LABEL_ALIGN -- only for labels in the middle of
functions, w/ alignment
   SYM_FUNC_INNER_LABEL -- only for labels in the middle of functions,
w/o alignment

   For functions with special (non-C) calling conventions:
   SYM_CODE_START -- use for non-C (special) functions
   SYM_CODE_START_NOALIGN -- use for non-C (special) functions, w/o
alignment
   SYM_CODE_START_LOCAL -- use for local non-C (special) functions
   SYM_CODE_START_LOCAL_NOALIGN -- use for local non-C (special)
functions, w/o alignment
   SYM_CODE_END -- the end of SYM_CODE_START_LOCAL or SYM_CODE_START

   SYM_CODE_INNER_LABEL_ALIGN -- only for labels in the middle of code
   SYM_CODE_INNER_LABEL -- only for labels in the middle of code

d) For data
   SYM_DATA_START -- global data symbol
   SYM_DATA_START_LOCAL -- local data symbol
   SYM_DATA_END -- the end of the SYM_DATA_START symbol
   SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
   SYM_DATA -- start+end wrapper around simple global data
   SYM_DATA_LOCAL -- start+end wrapper around simple local data

==

The macros allow to pair starts and ends of functions and mark functions
correctly in the output ELF objects.

All users of the old macros in x86 are converted to use these in further
patches.

[v2]
* use SYM_ prefix and sane names
* add SYM_START and SYM_END and parametrize all the macros

[v3]
* add SYM_DATA, SYM_DATA_LOCAL, and SYM_DATA_END_LABEL

[v4]
* add _NOALIGN versions of some macros
* add _CODE_ derivates of _FUNC_ macros

[v5]
* drop "SIMPLE" from data annotations
* switch NOALIGN and ALIGN variants of inner labels
* s/visibility/linkage/; s@SYM_V_@SYM_L_@
* add Documentation

Signed-off-by: Jiri Slaby 
Cc: Andrew Morton 
Cc: Boris Ostrovsky 
Cc: h...@zytor.com
Cc: Ingo Molnar 
Cc: jpoim...@redhat.com
Cc: Juergen Gross 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: mi...@redhat.com
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Thomas Gleixner 
Cc: xen-devel@lists.xenproject.org
Cc: x...@kernel.org
---
 Documentation/asm-annotations.rst | 218 
 arch/x86/include/asm/linkage.h|  10 +-
 include/linux/linkage.h   | 257 --
 3 files changed, 475 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/asm-annotations.rst

diff --git a/Documentation/asm-annotations.rst 
b/Documentation/asm-annotations.rst
new file mode 100644
index ..3e9b426347f0
--- /dev/null
+++ b/Documentation/asm-annotations.rst
@@ -0,0 +1,218 @@
+Assembler Annotations
+=
+
+Copyright (c) 2017 Jiri Slaby
+
+This document describes the new macros for annotation of data and code in

[Xen-devel] [PATCH -resend 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

[Jiri Slaby]

These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.

And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.

Signed-off-by: Jiri Slaby 
Reviewed-by: Rafael J. Wysocki  [hibernate]
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: x...@kernel.org
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: linux-cry...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S|  4 +-
 arch/x86/boot/compressed/head_64.S | 16 +++---
 arch/x86/boot/compressed/mem_encrypt.S |  8 +--
 arch/x86/crypto/aes-i586-asm_32.S  |  8 +--
 arch/x86/crypto/aes-x86_64-asm_64.S|  4 +-
 arch/x86/crypto/aes_ctrby8_avx-x86_64.S| 12 ++---
 arch/x86/crypto/aesni-intel_asm.S  | 60 +++---
 arch/x86/crypto/aesni-intel_avx-x86_64.S   | 24 -
 arch/x86/crypto/blowfish-x86_64-asm_64.S   | 16 +++---
 arch/x86/crypto/camellia-aesni-avx-asm_64.S| 24 -
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S   | 24 -
 arch/x86/crypto/camellia-x86_64-asm_64.S   | 16 +++---
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S  | 16 +++---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S  | 24 -
 arch/x86/crypto/chacha20-avx2-x86_64.S |  4 +-
 arch/x86/crypto/chacha20-ssse3-x86_64.S|  8 +--
 arch/x86/crypto/crc32-pclmul_asm.S |  4 +-
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S  |  4 +-
 arch/x86/crypto/crct10dif-pcl-asm_64.S |  4 +-
 arch/x86/crypto/des3_ede-asm_64.S  |  8 +--
 arch/x86/crypto/ghash-clmulni-intel_asm.S  |  8 +--
 arch/x86/crypto/poly1305-avx2-x86_64.S |  4 +-
 arch/x86/crypto/poly1305-sse2-x86_64.S |  8 +--
 arch/x86/crypto/salsa20-x86_64-asm_64.S|  4 +-
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S| 24 -
 arch/x86/crypto/serpent-avx2-asm_64.S  | 24 -
 arch/x86/crypto/serpent-sse2-x86_64-asm_64.S   |  8 +--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S   |  8 +--
 arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S  |  4 +-
 arch/x86/crypto/sha1-mb/sha1_x8_avx2.S |  4 +-
 arch/x86/crypto/sha1_avx2_x86_64_asm.S |  4 +-
 arch/x86/crypto/sha1_ni_asm.S  |  4 +-
 arch/x86/crypto/sha1_ssse3_asm.S   |  4 +-
 arch/x86/crypto/sha256-avx-asm.S   |  4 +-
 arch/x86/crypto/sha256-avx2-asm.S  |  4 +-
 .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S|  8 +--
 .../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S |  4 +-
 arch/x86/crypto/sha256-ssse3-asm.S |  4 +-
 arch/x86/crypto/sha256_ni_asm.S|  4 +-
 arch/x86/crypto/sha512-avx-asm.S   |  4 +-
 arch/x86/crypto/sha512-avx2-asm.S  |  4 +-
 .../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S|  8 +--
 .../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S   |  4 +-
 arch/x86/crypto/sha512-mb/sha512_x4_avx2.S |  4 +-
 arch/x86/crypto/sha512-ssse3-asm.S |  4 +-
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S| 24 -
 arch/x86/crypto/twofish-x86_64-asm_64-3way.S   |  8 +--
 arch/x86/crypto/twofish-x86_64-asm_64.S|  8 +--
 arch/x86/entry/entry_64.S  | 10 ++--
 arch/x86/entry/entry_64_compat.S   |  4 +-
 arch/x86/kernel/acpi/wakeup_64.S   |  8 +--
 arch/x86/kernel/ftrace_64.S| 20 
 arch/x86/kernel/head_64.S  | 12 ++---
 arch/x86/lib/checksum_32.S |  8 +--
 arch/x86/lib/clear_page_64.S   | 12 ++---
 arch/x86/lib/cmpxchg16b_emu.S  |  4 +-
 arch/x86/lib/cmpxchg8b_emu.S   |  4 +-
 arch/x86/lib/copy_page_64.S|  4 +-
 arch/x86/lib/copy_user_64.S| 16 +++---
 arch/x86/lib/csum-copy_64.S|  4 +-
 arch/x86/lib/getuser.S | 16 +++---
 arch/x86/lib/hweight.S |  8 +--
 

[Xen-devel] [PATCH -resend 08/27] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Reviewed-by: Juergen Gross  [xen parts]
Cc: 
Cc: 
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index b482ac1a1fb3..c85ecb163c78 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1761,8 +1761,7 @@ ENDPROC(aesni_gcm_finalize)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1773,8 +1772,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 SYM_FUNC_END(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 9a53a06e5a3e..4911b1c61aa8 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index bbec69d8223b..50c1648311b3 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -26,7 +26,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -208,6 +208,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 9bc861c71e75..927ac44d34aa 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -19,7 +19,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -43,8 +43,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 417b339e5c8e..e8f6f482bb20 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -164,13 +164,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.16.3


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

[Xen-devel] [PATCH -resend 22/27] x86_64: assembly, change all ENTRY+END to SYM_CODE_*

[Jiri Slaby]

Here, we change all code which is not marked as functions. In other
words, this code has been using END, not ENDPROC. So switch all of this
to appropriate new markings SYM_CODE_START and SYM_CODE_END.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/entry/entry_64.S| 56 
 arch/x86/entry/entry_64_compat.S |  8 +++---
 arch/x86/kernel/ftrace_64.S  |  4 +--
 arch/x86/xen/xen-asm_64.S|  8 +++---
 arch/x86/xen/xen-head.S  |  8 +++---
 5 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c6841c038170..1b0631971dde 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -46,11 +46,11 @@
 .section .entry.text, "ax"
 
 #ifdef CONFIG_PARAVIRT
-ENTRY(native_usergs_sysret64)
+SYM_CODE_START(native_usergs_sysret64)
UNWIND_HINT_EMPTY
swapgs
sysretq
-END(native_usergs_sysret64)
+SYM_CODE_END(native_usergs_sysret64)
 #endif /* CONFIG_PARAVIRT */
 
 .macro TRACE_IRQS_FLAGS flags:req
@@ -163,7 +163,7 @@ END(native_usergs_sysret64)
 #define RSP_SCRATCHCPU_ENTRY_AREA_entry_stack + \
SIZEOF_entry_stack - 8 + CPU_ENTRY_AREA
 
-ENTRY(entry_SYSCALL_64_trampoline)
+SYM_CODE_START(entry_SYSCALL_64_trampoline)
UNWIND_HINT_EMPTY
swapgs
 
@@ -193,17 +193,17 @@ ENTRY(entry_SYSCALL_64_trampoline)
pushq   %rdi
movq$entry_SYSCALL_64_stage2, %rdi
JMP_NOSPEC %rdi
-END(entry_SYSCALL_64_trampoline)
+SYM_CODE_END(entry_SYSCALL_64_trampoline)
 
.popsection
 
-ENTRY(entry_SYSCALL_64_stage2)
+SYM_CODE_START(entry_SYSCALL_64_stage2)
UNWIND_HINT_EMPTY
popq%rdi
jmp entry_SYSCALL_64_after_hwframe
-END(entry_SYSCALL_64_stage2)
+SYM_CODE_END(entry_SYSCALL_64_stage2)
 
-ENTRY(entry_SYSCALL_64)
+SYM_CODE_START(entry_SYSCALL_64)
UNWIND_HINT_EMPTY
/*
 * Interrupts are off on entry.
@@ -336,13 +336,13 @@ syscall_return_via_sysret:
popq%rdi
popq%rsp
USERGS_SYSRET64
-END(entry_SYSCALL_64)
+SYM_CODE_END(entry_SYSCALL_64)
 
 /*
  * %rdi: prev task
  * %rsi: next task
  */
-ENTRY(__switch_to_asm)
+SYM_CODE_START(__switch_to_asm)
UNWIND_HINT_FUNC
/*
 * Save callee-saved registers
@@ -384,7 +384,7 @@ ENTRY(__switch_to_asm)
popq%rbp
 
jmp __switch_to
-END(__switch_to_asm)
+SYM_CODE_END(__switch_to_asm)
 
 /*
  * A newly forked process directly context switches into this address.
@@ -393,7 +393,7 @@ END(__switch_to_asm)
  * rbx: kernel thread func (NULL for user thread)
  * r12: kernel thread arg
  */
-ENTRY(ret_from_fork)
+SYM_CODE_START(ret_from_fork)
UNWIND_HINT_EMPTY
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
@@ -419,14 +419,14 @@ ENTRY(ret_from_fork)
 */
movq$0, RAX(%rsp)
jmp 2b
-END(ret_from_fork)
+SYM_CODE_END(ret_from_fork)
 
 /*
  * Build the entry stubs with some assembler magic.
  * We pack 1 stub into every 8-byte block.
  */
.align 8
-ENTRY(irq_entries_start)
+SYM_CODE_START(irq_entries_start)
 vector=FIRST_EXTERNAL_VECTOR
 .rept (FIRST_SYSTEM_VECTOR - FIRST_EXTERNAL_VECTOR)
UNWIND_HINT_IRET_REGS
@@ -435,7 +435,7 @@ ENTRY(irq_entries_start)
.align  8
vector=vector+1
 .endr
-END(irq_entries_start)
+SYM_CODE_END(irq_entries_start)
 
 .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
 #ifdef CONFIG_DEBUG_ENTRY
@@ -561,7 +561,7 @@ END(irq_entries_start)
  * | return address|
  * ++
  */
-ENTRY(interrupt_entry)
+SYM_CODE_START(interrupt_entry)
UNWIND_HINT_FUNC
ASM_CLAC
cld
@@ -627,7 +627,7 @@ ENTRY(interrupt_entry)
TRACE_IRQS_OFF
 
ret
-END(interrupt_entry)
+SYM_CODE_END(interrupt_entry)
 
 
 /* Interrupt entry/exit. */
@@ -832,7 +832,7 @@ SYM_CODE_END(common_interrupt)
  * APIC interrupts.
  */
 .macro apicinterrupt3 num sym do_sym
-ENTRY(\sym)
+SYM_CODE_START(\sym)
UNWIND_HINT_IRET_REGS
pushq   $~(\num)
 .Lcommon_\sym:
@@ -840,7 +840,7 @@ ENTRY(\sym)
UNWIND_HINT_REGS indirect=1
call\do_sym /* rdi points to pt_regs */
jmp ret_from_intr
-END(\sym)
+SYM_CODE_END(\sym)
 .endm
 
 /* Make sure APIC interrupt handlers end up in the irqentry section: */
@@ -902,7 +902,7 @@ apicinterrupt IRQ_WORK_VECTOR   
irq_work_interrupt  smp_irq_work_interrupt
 #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) 

[Xen-devel] [PATCH -resend 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them (as global) using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Reviewed-by: Rafael J. Wysocki  [hibernate]
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: linux...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/entry/entry_32.S| 3 ++-
 arch/x86/kernel/acpi/wakeup_32.S | 7 ---
 arch/x86/kernel/ftrace_32.S  | 3 ++-
 arch/x86/kernel/head_32.S| 3 ++-
 arch/x86/power/hibernate_asm_32.S| 6 --
 arch/x86/realmode/rm/trampoline_32.S | 6 --
 arch/x86/xen/xen-asm_32.S| 7 ---
 7 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 66c688c15501..7742435271c1 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -376,9 +376,10 @@ SYM_ENTRY(__begin_SYSENTER_singlestep_region, 
SYM_L_GLOBAL, SYM_A_NONE)
  * Xen doesn't set %esp to be precisely what the normal SYSENTER
  * entry point expects, so fix it up before using the normal path.
  */
-ENTRY(xen_sysenter_target)
+SYM_CODE_START(xen_sysenter_target)
addl$5*4, %esp  /* remove xen-provided frame */
jmp .Lsysenter_past_esp
+SYM_CODE_END(xen_sysenter_target)
 #endif
 
 /*
diff --git a/arch/x86/kernel/acpi/wakeup_32.S b/arch/x86/kernel/acpi/wakeup_32.S
index feac1e5ecba0..71a05a6cc36a 100644
--- a/arch/x86/kernel/acpi/wakeup_32.S
+++ b/arch/x86/kernel/acpi/wakeup_32.S
@@ -8,8 +8,7 @@
.code32
ALIGN
 
-ENTRY(wakeup_pmode_return)
-wakeup_pmode_return:
+SYM_CODE_START(wakeup_pmode_return)
movw$__KERNEL_DS, %ax
movw%ax, %ss
movw%ax, %fs
@@ -38,6 +37,7 @@ wakeup_pmode_return:
# jump to place where we left off
movlsaved_eip, %eax
jmp *%eax
+SYM_CODE_END(wakeup_pmode_return)
 
 bogus_magic:
jmp bogus_magic
@@ -71,7 +71,7 @@ restore_registers:
popfl
ret
 
-ENTRY(do_suspend_lowlevel)
+SYM_CODE_START(do_suspend_lowlevel)
callsave_processor_state
callsave_registers
pushl   $3
@@ -86,6 +86,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_suspend_lowlevel)
 
 .data
 ALIGN
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 36ed448934ec..e2463acbd2f9 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -102,7 +102,7 @@ WEAK(ftrace_stub)
ret
 END(ftrace_caller)
 
-ENTRY(ftrace_regs_caller)
+SYM_CODE_START(ftrace_regs_caller)
/*
 * i386 does not save SS and ESP when coming from kernel.
 * Instead, to get sp, >sp is used (see ptrace.h).
@@ -170,6 +170,7 @@ SYM_CODE_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL)
lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */
 
jmp .Lftrace_ret
+SYM_CODE_END(ftrace_regs_caller)
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(function_hook)
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 1a6a6b4e4b4c..ba9df7cc545d 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -64,7 +64,7 @@ RESERVE_BRK(pagetables, INIT_MAP_SIZE)
  * can.
  */
 __HEAD
-ENTRY(startup_32)
+SYM_CODE_START(startup_32)
movl pa(initial_stack),%ecx

/* test KEEP_SEGMENTS flag to see if the bootloader is asking
@@ -172,6 +172,7 @@ num_subarch_entries = (. - subarch_entries) / 4
 #else
jmp .Ldefault_entry
 #endif /* CONFIG_PARAVIRT */
+SYM_CODE_END(startup_32)
 
 #ifdef CONFIG_HOTPLUG_CPU
 /*
diff --git a/arch/x86/power/hibernate_asm_32.S 
b/arch/x86/power/hibernate_asm_32.S
index 6e56815e13a0..3cd15e34aa87 100644
--- a/arch/x86/power/hibernate_asm_32.S
+++ b/arch/x86/power/hibernate_asm_32.S
@@ -15,7 +15,7 @@
 
 .text
 
-ENTRY(swsusp_arch_suspend)
+SYM_CODE_START(swsusp_arch_suspend)
movl %esp, saved_context_esp
movl %ebx, saved_context_ebx
movl %ebp, saved_context_ebp
@@ -26,8 +26,9 @@ ENTRY(swsusp_arch_suspend)
 
call swsusp_save
ret
+SYM_CODE_END(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
movlmmu_cr4_features, %ecx
movlresume_pg_dir, %eax
subl$__PAGE_OFFSET, %eax
@@ -83,3 +84,4 @@ done:
xorl%eax, %eax
 
ret
+SYM_CODE_END(restore_image)

[Xen-devel] [PATCH -resend 21/27] x86_64: assembly, add ENDs to some functions and relabel with SYM_CODE_*

[Jiri Slaby]

All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them (as global) using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky  [xen bits]
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/head_64.S   |  6 --
 arch/x86/platform/olpc/xo1-wakeup.S  |  3 ++-
 arch/x86/power/hibernate_asm_64.S|  6 --
 arch/x86/realmode/rm/reboot.S|  3 ++-
 arch/x86/realmode/rm/trampoline_64.S | 10 +++---
 arch/x86/realmode/rm/wakeup_asm.S|  3 ++-
 arch/x86/xen/xen-asm_64.S|  6 --
 7 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index a1a92f6fc8e4..d056c789f90d 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -250,7 +250,7 @@ ENDPROC(efi32_stub_entry)
 
.code64
.org 0x200
-ENTRY(startup_64)
+SYM_CODE_START(startup_64)
/*
 * 64bit entry is 0x200 and it is ABI so immutable!
 * We come here either from startup_32 or directly from a
@@ -400,6 +400,7 @@ trampoline_return:
  */
leaqrelocated(%rbx), %rax
jmp *%rax
+SYM_CODE_END(startup_64)
 
 #ifdef CONFIG_EFI_STUB
 
@@ -521,7 +522,7 @@ SYM_FUNC_END(relocated)
  * ECX contains the base address of the trampoline memory.
  * Non zero RDX on return means we need to enable 5-level paging.
  */
-ENTRY(trampoline_32bit_src)
+SYM_CODE_START(trampoline_32bit_src)
/* Set up data and stack segments */
movl$__KERNEL_DS, %eax
movl%eax, %ds
@@ -574,6 +575,7 @@ ENTRY(trampoline_32bit_src)
movl%eax, %cr0
 
lret
+SYM_CODE_END(trampoline_32bit_src)
 
.code64
 SYM_FUNC_START_LOCAL_NOALIGN(paging_enabled)
diff --git a/arch/x86/platform/olpc/xo1-wakeup.S 
b/arch/x86/platform/olpc/xo1-wakeup.S
index 5fee3a2c2fd4..75f4faff8468 100644
--- a/arch/x86/platform/olpc/xo1-wakeup.S
+++ b/arch/x86/platform/olpc/xo1-wakeup.S
@@ -90,7 +90,7 @@ restore_registers:
 
ret
 
-ENTRY(do_olpc_suspend_lowlevel)
+SYM_CODE_START(do_olpc_suspend_lowlevel)
callsave_processor_state
callsave_registers
 
@@ -110,6 +110,7 @@ ret_point:
callrestore_registers
callrestore_processor_state
ret
+SYM_CODE_END(do_olpc_suspend_lowlevel)
 
 .data
 saved_gdt: .long   0,0
diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..44755a847856 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -53,7 +53,7 @@ ENTRY(swsusp_arch_suspend)
ret
 ENDPROC(swsusp_arch_suspend)
 
-ENTRY(restore_image)
+SYM_CODE_START(restore_image)
/* prepare to jump to the image kernel */
movqrestore_jump_address(%rip), %r8
movqrestore_cr3(%rip), %r9
@@ -68,9 +68,10 @@ ENTRY(restore_image)
/* jump to relocated restore code */
movqrelocated_restore_code(%rip), %rcx
jmpq*%rcx
+SYM_CODE_END(restore_image)
 
/* code below has been relocated to a safe page */
-ENTRY(core_restore_code)
+SYM_CODE_START(core_restore_code)
/* switch to temporary page tables */
movq%rax, %cr3
/* flush TLB */
@@ -98,6 +99,7 @@ ENTRY(core_restore_code)
 .Ldone:
/* jump to the restore_registers address from the image header */
jmpq*%r8
+SYM_CODE_END(core_restore_code)
 
 /* code below belongs to the image kernel */
.align PAGE_SIZE
diff --git a/arch/x86/realmode/rm/reboot.S b/arch/x86/realmode/rm/reboot.S
index 6e38c13c1873..7db1459d363f 100644
--- a/arch/x86/realmode/rm/reboot.S
+++ b/arch/x86/realmode/rm/reboot.S
@@ -19,7 +19,7 @@
  */
.section ".text32", "ax"
.code32
-ENTRY(machine_real_restart_asm)
+SYM_CODE_START(machine_real_restart_asm)
 
 #ifdef CONFIG_X86_64
/* Switch to trampoline GDT as it is guaranteed < 4 GiB */
@@ -63,6 +63,7 @@ SYM_CODE_INNER_LABEL(machine_real_restart_paging_off, 
SYM_L_GLOBAL)
movl%ecx, %gs
movl%ecx, %ss
ljmpw   $8, $1f
+SYM_CODE_END(machine_real_restart_asm)
 
 /*
  * This is 16-bit protected mode code to disable paging and the cache,
diff --git a/arch/x86/realmode/rm/trampoline_64.S 
b/arch/x86/realmode/rm/trampoline_64.S
index 9e5f9ade43c8..408f81710ccd 100644
--- a/arch/x86/realmode/rm/trampoline_64.S
+++ b/arch/x86/realmode/rm/trampoline_64.S
@@ -38,7 +38,7 @@
.code16
 
.balign PAGE_SIZE
-ENTRY(trampoline_start)
+SYM_CODE_START(trampoline_start)
 

[Xen-devel] [PATCH -resend 19/27] x86: assembly, make some functions local

[Jiri Slaby]

There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on
ENDPROC/END for a particular function (C or non-C).

Signed-off-by: Jiri Slaby 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: x...@kernel.org
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: linux-...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/boot/compressed/efi_thunk_64.S |  8 
 arch/x86/entry/entry_64.S   | 21 +++--
 arch/x86/lib/copy_page_64.S |  4 ++--
 arch/x86/lib/memcpy_64.S| 12 ++--
 arch/x86/lib/memset_64.S|  8 
 arch/x86/platform/efi/efi_thunk_64.S| 12 ++--
 arch/x86/xen/xen-pvh.S  |  4 ++--
 7 files changed, 35 insertions(+), 34 deletions(-)

diff --git a/arch/x86/boot/compressed/efi_thunk_64.S 
b/arch/x86/boot/compressed/efi_thunk_64.S
index d66000d23921..31312070db22 100644
--- a/arch/x86/boot/compressed/efi_thunk_64.S
+++ b/arch/x86/boot/compressed/efi_thunk_64.S
@@ -99,12 +99,12 @@ ENTRY(efi64_thunk)
ret
 ENDPROC(efi64_thunk)
 
-ENTRY(efi_exit32)
+SYM_FUNC_START_LOCAL(efi_exit32)
movqfunc_rt_ptr(%rip), %rax
push%rax
mov %rdi, %rax
ret
-ENDPROC(efi_exit32)
+SYM_FUNC_END(efi_exit32)
 
.code32
 /*
@@ -112,7 +112,7 @@ ENDPROC(efi_exit32)
  *
  * The stack should represent the 32-bit calling convention.
  */
-ENTRY(efi_enter32)
+SYM_FUNC_START_LOCAL(efi_enter32)
movl$__KERNEL_DS, %eax
movl%eax, %ds
movl%eax, %es
@@ -172,7 +172,7 @@ ENTRY(efi_enter32)
btsl$X86_CR0_PG_BIT, %eax
movl%eax, %cr0
lret
-ENDPROC(efi_enter32)
+SYM_FUNC_END(efi_enter32)
 
.data
.balign 8
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index fda55310de2a..c6841c038170 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1068,7 +1068,8 @@ idtentry hypervisor_callback xen_do_hypervisor_callback 
has_error_code=0
  * existing activation in its critical region -- if so, we pop the current
  * activation and restart the handler using the previous one.
  */
-ENTRY(xen_do_hypervisor_callback)  /* 
do_hypervisor_callback(struct *pt_regs) */
+/* do_hypervisor_callback(struct *pt_regs) */
+SYM_CODE_START_LOCAL(xen_do_hypervisor_callback)
 
 /*
  * Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
@@ -1086,7 +1087,7 @@ ENTRY(xen_do_hypervisor_callback) /* 
do_hypervisor_callback(struct *pt_regs) */
callxen_maybe_preempt_hcall
 #endif
jmp error_exit
-END(xen_do_hypervisor_callback)
+SYM_CODE_END(xen_do_hypervisor_callback)
 
 /*
  * Hypervisor uses this for application faults while it executes.
@@ -1175,7 +1176,7 @@ idtentry machine_checkdo_mce  
has_error_code=0paranoid=1
  * Use slow, but surefire "are we in kernel?" check.
  * Return: ebx=0: need swapgs on exit, ebx=1: otherwise
  */
-ENTRY(paranoid_entry)
+SYM_CODE_START_LOCAL(paranoid_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1192,7 +1193,7 @@ ENTRY(paranoid_entry)
SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14
 
ret
-END(paranoid_entry)
+SYM_CODE_END(paranoid_entry)
 
 /*
  * "Paranoid" exit path from exception stack.  This is invoked
@@ -1206,7 +1207,7 @@ END(paranoid_entry)
  *
  * On entry, ebx is "no swapgs" flag (1: don't need swapgs, 0: need it)
  */
-ENTRY(paranoid_exit)
+SYM_CODE_START_LOCAL(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
TRACE_IRQS_OFF_DEBUG
@@ -1221,13 +1222,13 @@ ENTRY(paranoid_exit)
RESTORE_CR3 scratch_reg=%rbx save_reg=%r14
 .Lparanoid_exit_restore:
jmp restore_regs_and_return_to_kernel
-END(paranoid_exit)
+SYM_CODE_END(paranoid_exit)
 
 /*
  * Save all registers in pt_regs, and switch GS if needed.
  * Return: EBX=0: came from user mode; EBX=1: otherwise
  */
-ENTRY(error_entry)
+SYM_CODE_START_LOCAL(error_entry)
UNWIND_HINT_FUNC
cld
PUSH_AND_CLEAR_REGS save_ret=1
@@ -1314,7 +1315,7 @@ ENTRY(error_entry)
mov %rax, %rsp
decl%ebx
jmp .Lerror_entry_from_usermode_after_swapgs
-END(error_entry)
+SYM_CODE_END(error_entry)
 
 
 /*
@@ -1322,14 +1323,14 @@ END(error_entry)
  *   1: already in kernel mode, don't need SWAPGS
  *   0: user gsbase is loaded, we need SWAPGS and standard preparation for 
return to usermode
  */
-ENTRY(error_exit)
+SYM_CODE_START_LOCAL(error_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)

[Xen-devel] [PATCH -resend 13/27] x86: xen-pvh, annotate data appropriatelly

[Jiri Slaby]

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros:
   8 OBJECT  LOCAL  DEFAULT6 gdt
  000832 OBJECT  LOCAL  DEFAULT6 gdt_start
  0028 0 OBJECT  LOCAL  DEFAULT6 gdt_end
  0028   256 OBJECT  LOCAL  DEFAULT6 early_stack
  0128 0 OBJECT  LOCAL  DEFAULT6 early_stack

Signed-off-by: Jiri Slaby 
Reviewed-by: Boris Ostrovsky 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: xen-devel@lists.xenproject.org
---
 arch/x86/xen/xen-pvh.S | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbeae08d..52b28793a625 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -137,11 +137,12 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
-gdt:
+SYM_DATA_START_LOCAL(gdt)
.word gdt_end - gdt_start
.long _pa(gdt_start)
.word 0
-gdt_start:
+SYM_DATA_END(gdt)
+SYM_DATA_START_LOCAL(gdt_start)
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
 #ifdef CONFIG_X86_64
@@ -150,12 +151,12 @@ gdt_start:
.quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
 #endif
.quad GDT_ENTRY(0xc092, 0, 0xf) /* __KERNEL_DS */
-gdt_end:
+SYM_DATA_END_LABEL(gdt_start, SYM_L_LOCAL, gdt_end)
 
.balign 4
-early_stack:
+SYM_DATA_START_LOCAL(early_stack)
.fill 256, 1, 0
-early_stack_end:
+SYM_DATA_END_LABEL(early_stack, SYM_L_LOCAL, early_stack_end)
 
ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,
 _ASM_PTR (pvh_start_xen - __START_KERNEL_map))
-- 
2.16.3


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

Re: [Xen-devel] [PATCH v3 06/10] xen/common: Restore IRQ affinity when hotplugging a pCPU

[Dario Faggioli]

On Fri, 2018-04-27 at 19:12 +0200, Mirela Simonovic wrote:
> Non-boot pCPUs are being hot-unplugged during the system suspend to
> RAM and hotplugged during the resume. When non-boot pCPUs are
> hot-unplugged the interrupts that were targeted to them are migrated
> to the boot pCPU.
> On suspend, each guest could have its own wake-up devices/interrupts
> (passthrough) that could trigger the system resume. These interrupts
> could be targeted to a non-boot pCPU, e.g. if the guest's vCPU is
> pinned to a non-boot pCPU. Due to the hot-unplug of non-boot pCPUs
> during the suspend such interrupts will be migrated from non-boot
> pCPUs
> to the boot pCPU (this is fine). However, when non-boot pCPUs are
> hotplugged on resume, these interrupts are not migrated back to non-
> boot
> pCPUs, i.e. IRQ affinity is not restored on resume (this is wrong).
> This patch adds the restoration of IRQ affinity when a pCPU is
> hotplugged.
> 
> Signed-off-by: Mirela Simonovic 
> 
> ---
> CC: George Dunlap 
> CC: Dario Faggioli 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Olaf Hering]

Am Wed, 9 May 2018 14:43:17 -0700 (PDT)
schrieb Stefano Stabellini :

> 512b109ec962 is a very old commit: why is it causing problems to Xen
> 4.10 and Xen 4.11 HVM migration? What is the error exactly? Sorry, I
> might be missing some context.

It is papering over the real issue, thats why one can still migrate a
pvops HVM domU with current toolstack. Upstream kernel simply does the
work that is supposed to be done by qemu itself. Since the xenlinux based
kernel does not do that work (it never had a need to do the unplug twice),
migration fails.

qemu has to carry the unplug state from one dom0 to another dom0 during
migration, simply because unplug is a one-time operation that can not 
be undone. I wonder how to do that, if qemu already has code to carry its
state.

Olaf


pgp_mVFECcnJC.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel