[Xen-devel] [xen-unstable-smoke test] 116655: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 116635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  11e7dd958de73a45645bd40d82280660bd2c9ee8
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis   116635  2017-11-28 19:01:40 Z0 days
Testing same since   116639  2017-11-28 22:28:10 Z0 days4 attempts


People who touched revisions under test:
  Andre Przywara 
  Stewart Hildebrand 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit 11e7dd958de73a45645bd40d82280660bd2c9ee8
Author: Stewart Hildebrand 
Date:   Tue Nov 28 14:42:03 2017 +

xen/arm: domain_builder: irq sanity check logic fix

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Julien Grall 
Release-acked-by: Julien Grall 

commit 31309b538f77a9eac5b9d1308335612ebd96bd3d
Author: Andre Przywara 
Date:   Thu Nov 16 12:02:35 2017 +

arm64: ITS: fix cacheability adjustment

If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However we fail horribly in doing computer science 101 bit
masking, effectively clearing the whole register instead of just a few
bits.
Fix this by removing the one redundant masking operation and adding the
magic negation for the actually needed other operation.

Reported-by: Manish Jaggi 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
Release-Acked-by: Julien Grall 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH 0/3] x86: make rsdp address accessible via boot params

[Juergen Gross]

On 28/11/17 22:03, Rafael J. Wysocki wrote:
> On Tue, Nov 28, 2017 at 10:43 AM, Juergen Gross  wrote:
>> In the non-EFI boot path the ACPI RSDP table is currently found via
>> either EBDA or by searching through low memory for the RSDP magic.
>> This requires the RSDP to be located in the first 1MB of physical
>> memory. Xen PVH guests, however, get the RSDP address via the start of
>> day information block.
>>
>> In order to support an arbitrary RSDP address this patch series adds
>> the physical address of the RSDP to the boot params structure filled
>> by the boot loader. A kernel booted directly in PVH mode can save the
>> RSDP address in the boot params, while a kernel booted in PVH mode via
>> grub can rely on the RSDP address being specified by grub2 (which in
>> turn got the address via the start of day information block from Xen).
>>
>> Juergen Gross (3):
>>   x86/boot: add acpi rsdp address to setup_header
>>   x86/acpi: take rsdp address for boot params if available
>>   x86/xen: supply rsdp address in boot params for pvh guests
>>
>>  Documentation/x86/boot.txt| 19 +++
>>  arch/x86/boot/header.S|  6 +-
>>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>>  arch/x86/xen/enlighten_pvh.c  |  2 ++
>>  drivers/acpi/osl.c|  8 
>>  5 files changed, 35 insertions(+), 1 deletion(-)
>>
>> --
> 
> Is this going to work with all existing setups?

I think so, yes.

In EFI environment this doesn't matter, direct PVH boot is working,
grub2 support is optional (without grub2 support things are working as
today).

I'm already writing grub2 patches to support booting in PVH environment.
Those were the reason I need this patch set, as otherwise Xen would have
to put the RSDP into low memory which is limiting the guest's ability to
use large page mappings for all its memory.

Additionally something like this is needed for PVH dom0 support anyway.


Juergen

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

[Xen-devel] [xen-4.5-testing test] 116622: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 116356

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 116356
 test-xtf-amd64-amd64-2   60 leak-check/check fail  like 116356
 test-xtf-amd64-amd64-3   60 leak-check/check fail  like 116356
 test-xtf-amd64-amd64-1   60 leak-check/check fail  like 116356
 test-xtf-amd64-amd64-5   60 leak-check/check fail  like 116356
 test-xtf-amd64-amd64-4   60 leak-check/check fail  like 116356
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116356
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116356
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116356
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116356
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116356
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116356
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-localmigrate/x10 fail like 
116356
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-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-libvirt-raw 11 guest-start  fail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 

[Xen-devel] [xen-unstable-smoke test] 116650: regressions - trouble: blocked/broken/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   5 host-build-prep  fail REGR. vs. 116635

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  11e7dd958de73a45645bd40d82280660bd2c9ee8
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis   116635  2017-11-28 19:01:40 Z0 days
Testing same since   116639  2017-11-28 22:28:10 Z0 days3 attempts


People who touched revisions under test:
  Andre Przywara 
  Stewart Hildebrand 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-armhf broken

Not pushing.


commit 11e7dd958de73a45645bd40d82280660bd2c9ee8
Author: Stewart Hildebrand 
Date:   Tue Nov 28 14:42:03 2017 +

xen/arm: domain_builder: irq sanity check logic fix

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Julien Grall 
Release-acked-by: Julien Grall 

commit 31309b538f77a9eac5b9d1308335612ebd96bd3d
Author: Andre Przywara 
Date:   Thu Nov 16 12:02:35 2017 +

arm64: ITS: fix cacheability adjustment

If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However we fail horribly in doing computer science 101 bit
masking, effectively clearing the whole register instead of just a few
bits.
Fix this by removing the one redundant masking operation and adding the
magic negation for the actually needed other operation.

Reported-by: Manish Jaggi 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
Release-Acked-by: Julien Grall 
(qemu changes not included)

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

[Xen-devel] [xen-unstable-smoke test] 116645: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 116635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  11e7dd958de73a45645bd40d82280660bd2c9ee8
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis   116635  2017-11-28 19:01:40 Z0 days
Testing same since   116639  2017-11-28 22:28:10 Z0 days2 attempts


People who touched revisions under test:
  Andre Przywara 
  Stewart Hildebrand 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit 11e7dd958de73a45645bd40d82280660bd2c9ee8
Author: Stewart Hildebrand 
Date:   Tue Nov 28 14:42:03 2017 +

xen/arm: domain_builder: irq sanity check logic fix

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Julien Grall 
Release-acked-by: Julien Grall 

commit 31309b538f77a9eac5b9d1308335612ebd96bd3d
Author: Andre Przywara 
Date:   Thu Nov 16 12:02:35 2017 +

arm64: ITS: fix cacheability adjustment

If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However we fail horribly in doing computer science 101 bit
masking, effectively clearing the whole register instead of just a few
bits.
Fix this by removing the one redundant masking operation and adding the
magic negation for the actually needed other operation.

Reported-by: Manish Jaggi 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
Release-Acked-by: Julien Grall 
(qemu changes not included)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

Last test of basis   116463  2017-11-23 02:49:04 Z5 days
Testing same since   116619  2017-11-28 12:49:51 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Julien Grall 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass

[Xen-devel] [xen-unstable-smoke test] 116639: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 116635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  11e7dd958de73a45645bd40d82280660bd2c9ee8
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis   116635  2017-11-28 19:01:40 Z0 days
Testing same since   116639  2017-11-28 22:28:10 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Stewart Hildebrand 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Not pushing.


commit 11e7dd958de73a45645bd40d82280660bd2c9ee8
Author: Stewart Hildebrand 
Date:   Tue Nov 28 14:42:03 2017 +

xen/arm: domain_builder: irq sanity check logic fix

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 
Reviewed-by: Julien Grall 
Release-acked-by: Julien Grall 

commit 31309b538f77a9eac5b9d1308335612ebd96bd3d
Author: Andre Przywara 
Date:   Thu Nov 16 12:02:35 2017 +

arm64: ITS: fix cacheability adjustment

If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However we fail horribly in doing computer science 101 bit
masking, effectively clearing the whole register instead of just a few
bits.
Fix this by removing the one redundant masking operation and adding the
magic negation for the actually needed other operation.

Reported-by: Manish Jaggi 
Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
Release-Acked-by: Julien Grall 
(qemu changes not included)

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

[Xen-devel] [xen-unstable test] 116614: FAIL

[osstest service owner]

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

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 116596
 test-amd64-i386-libvirt-xsm   3 syslog-serverrunning in 116596
 test-amd64-i386-libvirt-xsm  22 capture-logs(22) running in 116596

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 14 guest-localmigrate fail pass 
in 116596
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 14 guest-localmigrate fail pass 
in 116596

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 116596 like 116518
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 116596 like 116571
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116571
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116571
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 116571
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116571
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116571
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116571
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116571
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116571
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116571
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116571
 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-i386-libvirt-xsm  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-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-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-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  345bb9cd634421f50b732d4f9c89a649a7a1d0db
baseline version:
 xen  bf87b7f7d91a25404216e0a0f3e628ce9bf1f82e

Last test of basis   116571  2017-11-27 02:08:19 Z1 days
Testing same since   116596  2017-11-27 20:26:46 Z1 days2 attempts


People who touched revisions under test:
  George Dunlap 

[Xen-devel] [seabios test] 116616: regressions - FAIL

[osstest service owner]

flight 116616 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116616/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  df46d10c8a7b88eb82f3ceb2aa31782dee15593d
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   25 days
Failing since115733  2017-11-10 17:19:59 Z   18 days   32 attempts
Testing same since   116211  2017-11-16 00:20:45 Z   12 days   22 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Signed-off-by: Kevin O'Connor 

commit 9ce6778f08c632c52b25bc8f754291ef18710d53
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:16:36 2017 -0500

docs: Add sercon-port to Runtime_config.md documentation

Signed-off-by: Kevin O'Connor 

[Xen-devel] [xen-unstable-smoke test] 116635: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c
baseline version:
 xen  7f080956e9eed821fd42013bef11c1a2873fbeba

Last test of basis   116621  2017-11-28 13:21:40 Z0 days
Testing same since   116635  2017-11-28 19:01:40 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   7f08095..9976f38  9976f3874d4cca829f2d2916feab18615337bb5c -> smoke

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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

[Tamas K Lengyel]

On Tue, Nov 28, 2017 at 12:00 PM, Andrew Cooper
 wrote:
> On 28/11/17 18:06, Tamas K Lengyel wrote:
>> From: Tamas K Lengyel 
>>
>> Currently the built-in XSM policy only gets used if there is no other policy
>> specified during boot. In this patch we add a Kconfig option to specify to 
>> only
>> use built-in policy during boot. This is particularly important when booting
>> Xen through the shim to ensure the XSM policy gets measured and that it can't
>> be replaced by another unmeasured policy by the bootloader. Note that the XSM
>> policy can still be updated after boot (from dom0 for example) if the 
>> built-in
>> policy allows it.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Andrew Cooper 
>> Cc: George Dunlap 
>> Cc: Ian Jackson 
>> Cc: Jan Beulich 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Stefano Stabellini 
>> Cc: Tim Deegan 
>> Cc: Wei Liu 
>> Cc: Daniel De Graaf 
>> Cc: ope...@googlegroups.com
>> ---
>>  xen/common/Kconfig | 14 ++
>>  xen/xsm/xsm_core.c |  2 ++
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 103ef44cb5..5ad0d03f37 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -140,6 +140,20 @@ config XSM_POLICY
>>
>> If unsure, say Y.
>>
>> +config XSM_POLICY_OVERRIDE
>> + bool "Built-in security policy overrides bootloader provided policy"
>
> The overall change certainly looks good and it is obvious why it is a
> benefit.  However, text/functionality like this is cognitively hard to
> follow, and _OVERRIDE isn't obviously as to its functionality at a glance.
>
> Wouldn't it be better to have XSM_BOOTLOADER_POLICY (or possibly
> XSM_ALLOW_?), which defaults to y, and can be forced off for extra security?
>

I'm certainly open to alternate naming suggestions. The current one is
based on an existing option that implements a similar feature with
this naming (CMDLINE_OVERRIDE), while the XSM_POLICY part is from the
existing XSM_POLICY option.

Tamas

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

Re: [Xen-devel] [PATCH] xen/arm: domain_builder: irq sanity check logic fix

[Julien Grall]

Hi Stewart,

On 11/28/2017 02:42 PM, Stewart Hildebrand wrote:

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 


Whoops. Well spotted!

Reviewed-by: Julien Grall 

Also, I think it would be good to get the patch merge in Xen 4.10. It is 
boot code and low risk. So:


Release-acked-by: Julien Grall 

Cheers,


---
  xen/arch/arm/domain_build.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c74f4dd..f50f8b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -501,9 +501,10 @@ static void set_interrupt_ppi(gic_interrupt_t interrupt, 
unsigned int irq,
  {
  __be32 *cells = interrupt;
  
-BUG_ON(irq < 16 && irq >= 32);

+BUG_ON(irq < 16);
+BUG_ON(irq >= 32);
  
-/* See linux Documentation/devictree/bindings/arm/gic.txt */

+/* See linux 
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
  dt_set_cell(, 1, 1); /* is a PPI */
  dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
  dt_set_cell(, 1, (cpumask << 8) | level);



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

Re: [Xen-devel] [PATCH] arm64: ITS: fix cacheability adjustment

[Julien Grall]

On 11/28/2017 02:05 PM, Andre Przywara wrote:

Hi,


Hi Andre,

Sorry someone I skipped that patch :/.


On 16/11/17 12:02, Andre Przywara wrote:

If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However we fail horribly in doing computer science 101 bit
masking, effectively clearing the whole register instead of just a few
bits.
Fix this by removing the one redundant masking operation and adding the
magic negation for the actually needed other operation.

Reported-by: Manish Jaggi 


Manish, can you please test this patch and confirm that it works?
Also how does the bug manifest for you?

Julien, Stefano: Are there any objections against taking this patch for > 4.10? 
This was introduced with the ITS emulation.


Reviewed-by: Julien Grall 

This is new code and in technical preview. So I think it is fine to get 
them in Xen 4.10.


Release-Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

[Andrew Cooper]

On 28/11/17 18:06, Tamas K Lengyel wrote:
> From: Tamas K Lengyel 
>
> Currently the built-in XSM policy only gets used if there is no other policy
> specified during boot. In this patch we add a Kconfig option to specify to 
> only
> use built-in policy during boot. This is particularly important when booting
> Xen through the shim to ensure the XSM policy gets measured and that it can't
> be replaced by another unmeasured policy by the bootloader. Note that the XSM
> policy can still be updated after boot (from dom0 for example) if the built-in
> policy allows it.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Daniel De Graaf 
> Cc: ope...@googlegroups.com
> ---
>  xen/common/Kconfig | 14 ++
>  xen/xsm/xsm_core.c |  2 ++
>  2 files changed, 16 insertions(+)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 103ef44cb5..5ad0d03f37 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -140,6 +140,20 @@ config XSM_POLICY
>  
> If unsure, say Y.
>  
> +config XSM_POLICY_OVERRIDE
> + bool "Built-in security policy overrides bootloader provided policy"

The overall change certainly looks good and it is obvious why it is a
benefit.  However, text/functionality like this is cognitively hard to
follow, and _OVERRIDE isn't obviously as to its functionality at a glance.

Wouldn't it be better to have XSM_BOOTLOADER_POLICY (or possibly
XSM_ALLOW_?), which defaults to y, and can be forced off for extra security?

~Andrew

> + default n
> + depends on XSM && XSM_POLICY
> + ---help---
> +   Set this option to 'Y' to have the hypervisor ignore the security
> +   policy provided by the bootloader, and use ONLY the built-in
> +   security policy.
> +
> +   This can be used to ensure only verified security policies are
> +   loaded during boot time.
> +
> +   If unsure, say N.
> +
>  config LATE_HWDOM
>   bool "Dedicated hardware domain"
>   default n
>


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

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/28/2017 04:12 AM, Christian König wrote:
>
>
> How about the attached patch? It limits the newly added MMIO space to
> the upper 256GB of the address space. That should still be enough for
> most devices, but we avoid both issues with Xen dom0 as most likely
> problems with memory hotplug as well.

It certainly makes the problem to be less likely so I guess we could do
this for now.

Thanks.
-boris


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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

[Daniel De Graaf]

On 11/28/2017 01:06 PM, Tamas K Lengyel wrote:

From: Tamas K Lengyel 

Currently the built-in XSM policy only gets used if there is no other policy
specified during boot. In this patch we add a Kconfig option to specify to only
use built-in policy during boot. This is particularly important when booting
Xen through the shim to ensure the XSM policy gets measured and that it can't
be replaced by another unmeasured policy by the bootloader. Note that the XSM
policy can still be updated after boot (from dom0 for example) if the built-in
policy allows it.

Signed-off-by: Tamas K Lengyel 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 1/6] machine: Replace has_dynamic_sysbus with list of allowed devices

[Marc-André Lureau]

Hi

On Sat, Nov 25, 2017 at 4:16 PM, Eduardo Habkost  wrote:
> The existing has_dynamic_sysbus flag makes the machine accept
> every user-creatable sysbus device type on the command-line.
> Replace it with a list of allowed device types, so machines can
> easily accept some sysbus devices while rejecting others.
>
> To keep exactly the same behavior as before, the existing
> has_dynamic_sysbus=true assignments are replaced with a
> TYPE_SYS_BUS_DEVICE entry on the allowed list.  Other patches
> will replace the TYPE_SYS_BUS_DEVICE entries with more specific
> lists of devices.
>
> Cc: Peter Maydell 
> Cc: Marcel Apfelbaum 
> Cc: "Michael S. Tsirkin" 
> Cc: Alexander Graf 
> Cc: David Gibson 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: qemu-...@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: xen-devel@lists.xenproject.org
> Signed-off-by: Eduardo Habkost 

Reviewed-by: Marc-André Lureau 

> ---
> Changes v1 -> v2:
> * Replace "dynamic sysbus whitelist" with "allowed sysbus devices"
> * Simply add TYPE_SYS_BUS_DEVICE to the list on existing
>   has_dynamic_sysbus=true machines, and make machine-types more
>   strict in separate patches
> ---
>  include/hw/boards.h  |  5 -
>  hw/arm/virt.c|  3 ++-
>  hw/core/machine.c| 43 +--
>  hw/i386/pc_q35.c |  3 ++-
>  hw/ppc/e500plat.c|  4 +++-
>  hw/ppc/spapr.c   |  3 ++-
>  hw/xen/xen_backend.c |  7 ++-
>  7 files changed, 48 insertions(+), 20 deletions(-)
>
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 156b16f7a6..041bc08971 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -76,6 +76,9 @@ void machine_set_cpu_numa_node(MachineState *machine,
> const CpuInstanceProperties *props,
> Error **errp);
>
> +void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char 
> *type);
> +
> +
>  /**
>   * CPUArchId:
>   * @arch_id - architecture-dependent CPU ID of present or possible CPU
> @@ -179,7 +182,6 @@ struct MachineClass {
>  no_floppy:1,
>  no_cdrom:1,
>  no_sdcard:1,
> -has_dynamic_sysbus:1,
>  pci_allow_0_address:1,
>  legacy_fw_cfg_order:1;
>  int is_default;
> @@ -197,6 +199,7 @@ struct MachineClass {
>  bool ignore_memory_transaction_failures;
>  int numa_mem_align_shift;
>  const char **valid_cpu_types;
> +strList *allowed_dynamic_sysbus_devices;
>  bool auto_enable_numa_with_memhp;
>  void (*numa_auto_assign_ram)(MachineClass *mc, NodeInfo *nodes,
>   int nb_nodes, ram_addr_t size);
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 9e18b410d7..fa6dc15fcd 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1591,7 +1591,8 @@ static void virt_machine_class_init(ObjectClass *oc, 
> void *data)
>   * configuration of the particular instance.
>   */
>  mc->max_cpus = 255;
> -mc->has_dynamic_sysbus = true;
> +/*TODO: allow only sysbus devices that really work with this machine */

cosmetic: why do you not leave a space between * and TODO ? (you did
that repeatedly)

> +machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
>  mc->block_default_type = IF_VIRTIO;
>  mc->no_cdrom = 1;
>  mc->pci_allow_0_address = true;
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 36c2fb069c..ab2ec292f3 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -335,29 +335,44 @@ static bool machine_get_enforce_config_section(Object 
> *obj, Error **errp)
>  return ms->enforce_config_section;
>  }
>
> -static void error_on_sysbus_device(SysBusDevice *sbdev, void *opaque)
> +void machine_class_allow_dynamic_sysbus_dev(MachineClass *mc, const char 
> *type)
>  {
> -error_report("Option '-device %s' cannot be handled by this machine",
> - object_class_get_name(object_get_class(OBJECT(sbdev;
> -exit(1);
> +strList *item = g_new0(strList, 1);
> +
> +item->value = g_strdup(type);
> +item->next = mc->allowed_dynamic_sysbus_devices;
> +mc->allowed_dynamic_sysbus_devices = item;
>  }
>
> -static void machine_init_notify(Notifier *notifier, void *data)
> +static void validate_sysbus_device(SysBusDevice *sbdev, void *opaque)
>  {
> -Object *machine = qdev_get_machine();
> -ObjectClass *oc = object_get_class(machine);
> -MachineClass *mc = MACHINE_CLASS(oc);
> +MachineState *machine = opaque;
> +MachineClass *mc = MACHINE_GET_CLASS(machine);
> +bool allowed = false;
> +strList *wl;
>
> -if (mc->has_dynamic_sysbus) {
> -/* Our machine can handle dynamic sysbus devices, we're all good */
> -return;
> +for (wl = 

Re: [Xen-devel] [PATCH v4 5/7] x86/cpuid: update signature of hvm_cr4_guest_valid_bits()

[Jan Beulich]

>>> On 18.10.17 at 10:27,  wrote:
> With the new cpuid infrastructure there is a domain-wide struct cpuid
> policy and there is no need to pass a separate struct vcpu * into
> hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
> domain * instead and update callers.
> 
> Signed-off-by: Sergey Dyasli 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v4 4/7] x86/msr: add VMX MSRs into HVM_max domain policy

[Jan Beulich]

>>> On 18.10.17 at 10:27,  wrote:
> +static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)
> +{
> +if ( !cpu_has_vmx )
> +return;
> +
> +dp->vmx.basic.raw = host_msr_domain_policy.vmx.basic.raw;
> +
> +dp->vmx.pinbased_ctls.raw = ((uint64_t) VMX_PINBASED_CTLS_DEFAULT1 << 
> 32) |

Stray blank after cast.

> +VMX_PINBASED_CTLS_DEFAULT1;
> +vmx_host_allowed_cpyb(dp, vmx, pinbased_ctls, ext_intr_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, pinbased_ctls, nmi_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, pinbased_ctls, preempt_timer);
> +
> +dp->vmx.procbased_ctls.raw =
> +((uint64_t) VMX_PROCBASED_CTLS_DEFAULT1 << 32) |

Again.

> +VMX_PROCBASED_CTLS_DEFAULT1;
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, virtual_intr_pending);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, use_tsc_offseting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, hlt_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, invlpg_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, mwait_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, rdpmc_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, rdtsc_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, cr8_load_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, cr8_store_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, tpr_shadow);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, virtual_nmi_pending);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, mov_dr_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, uncond_io_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, activate_io_bitmap);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, monitor_trap_flag);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, activate_msr_bitmap);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, monitor_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, pause_exiting);
> +vmx_host_allowed_cpyb(dp, vmx, procbased_ctls, 
> activate_secondary_controls);

This looks pretty ugly and hard to maintain to me. Wouldn't it be
possible to have static const instances of the structures describing
which fields should come from where, allowing simple & and | to
be done on the raw fields instead. I understand we won't get
away without listing the individual bits, but the overhead here is
far higher than if there was a simple initializer line for each field.

Jan


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

Re: [Xen-devel] [PATCH v4 3/7] x86/msr: read VMX MSRs values into Raw policy

[Jan Beulich]

>>> On 18.10.17 at 10:27,  wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -32,6 +32,37 @@ struct msr_domain_policy __read_mostly 
> raw_msr_domain_policy,
>  struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
> __read_mostly  pv_max_msr_vcpu_policy;
>  
> +static void __init calculate_raw_vmx_policy(struct msr_domain_policy *dp)
> +{
> +unsigned int i;
> +
> +if ( !cpu_has_vmx )
> +return;
> +
> +for ( i = MSR_IA32_VMX_BASIC; i <= MSR_IA32_VMX_VMCS_ENUM; i++ )
> +rdmsrl(i, dp->vmx.raw[i - MSR_IA32_VMX_BASIC]);
> +
> +if ( dp->vmx.procbased_ctls.allowed_1.activate_secondary_controls )
> +{
> +rdmsrl(MSR_IA32_VMX_PROCBASED_CTLS2, dp->vmx_procbased_ctls2.raw);
> +
> +if ( dp->vmx_procbased_ctls2.allowed_1.enable_ept ||
> + dp->vmx_procbased_ctls2.allowed_1.enable_vpid )
> +rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, dp->vmx_ept_vpid_cap.raw);

For consistency please either move this out of the if() or ...

> +}
> +
> +if ( dp->vmx.basic.default1_zero )
> +{
> +for ( i = MSR_IA32_VMX_TRUE_PINBASED_CTLS;
> +  i <= MSR_IA32_VMX_TRUE_ENTRY_CTLS; i++ )
> +rdmsrl(i,
> +   dp->vmx_true_ctls.raw[i - 
> MSR_IA32_VMX_TRUE_PINBASED_CTLS]);
> +}
> +
> +if ( dp->vmx_procbased_ctls2.allowed_1.enable_vm_functions )
> +rdmsrl(MSR_IA32_VMX_VMFUNC, dp->vmx_vmfunc.raw);

... move this one into that same if() above.

Jan


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

[Xen-devel] [PATCH v14 02/11] x86/hvm/ioreq: simplify code and use consistent naming

[Paul Durrant]

This patch re-works much of the ioreq server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 

v3:
 - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes.
 - Minor updates in response to review comments from Roger.
---
 xen/arch/x86/hvm/ioreq.c | 182 ++-
 1 file changed, 69 insertions(+), 113 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index da31918bb1..c21fa9f280 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,63 +210,75 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!IS_DEFAULT(s));
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-{
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
-}
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!IS_DEFAULT(s));
+ASSERT(gfn != gfn_x(INVALID_GFN));
+
+set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(>va, iorp->page);
+iorp->page = NULL;
+
+if ( !IS_DEFAULT(s) )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, , )) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( IS_DEFAULT(s) )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-return 0;
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
+
+rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -279,8 +291,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 
 FOR_EACH_IOREQ_SERVER(d, id, s)
 {
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -292,20 +303,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+

[Xen-devel] [PATCH v14 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Paul Durrant]

A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.

This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
Cc: Ian Jackson 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 

v8:
 - For safety make all of the pointers passed to
   hvm_get_ioreq_server_info() optional.
 - Shrink bufioreq_handling down to a uint8_t.

v3:
 - Updated in response to review comments from Wei and Roger.
 - Added a HANDLE_BUFIOREQ macro to make the code neater.
 - This patch no longer introduces a security vulnerability since there
   is now an explicit limit on the number of ioreq servers that may be
   created for any one domain.
---
 tools/libs/devicemodel/core.c   |  8 +
 tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
 xen/arch/x86/hvm/dm.c   |  9 +++--
 xen/arch/x86/hvm/ioreq.c| 47 ++---
 xen/include/asm-x86/hvm/domain.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 32 ++---
 6 files changed, 63 insertions(+), 41 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index b66d4f9294..e684e657b6 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -204,6 +204,14 @@ int xendevicemodel_get_ioreq_server_info(
 
 data->id = id;
 
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags |= XEN_DMOP_no_gfns;
+
 rc = xendevicemodel_op(dmod, domid, 1, , sizeof(op));
 if (rc)
 return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index dda0bc7695..fffee3a4a0 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gfn
+ *  gfn. (May be NULL if not required)
  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gfn. (May be NULL if not required)
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index a787f43737..3c617bd754 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args)
 {
 struct xen_dm_op_get_ioreq_server_info *data =
 _ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
 
 const_op = false;
 
 rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   >ioreq_gfn,
-   >bufioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >ioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : >bufioreq_gfn,
>bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index eec4e4771e..39de659ddf 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -350,6 +350,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 }
 
+#define HANDLE_BUFIOREQ(s) \
+((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
+
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
  struct vcpu *v)
 {
@@ 

[Xen-devel] [PATCH v14 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

[Paul Durrant]

This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/ioreq.c | 44 
 xen/include/asm-x86/hvm/domain.h |  2 +-
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index c21fa9f280..eec4e4771e 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -210,7 +210,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 unsigned int i;
@@ -220,20 +220,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct 
hvm_ioreq_server *s)
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, >arch.hvm_domain.ioreq_gfn.mask) )
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
 }
 
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
 }
 
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
-   unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 {
 struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
 
 ASSERT(!IS_DEFAULT(s));
-ASSERT(gfn != gfn_x(INVALID_GFN));
+ASSERT(!gfn_eq(gfn, INVALID_GFN));
 
 set_bit(i, >arch.hvm_domain.ioreq_gfn.mask);
 }
@@ -242,7 +241,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
 destroy_ring_for_helper(>va, iorp->page);
@@ -251,7 +250,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 if ( !IS_DEFAULT(s) )
 hvm_free_ioreq_gfn(s, iorp->gfn);
 
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
 }
 
 static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -264,16 +263,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return -EINVAL;
 
 if ( IS_DEFAULT(s) )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
 else
 iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return -ENOMEM;
 
-rc = prepare_ring_for_helper(d, iorp->gfn, >page, >va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), >page,
+ >va);
 
 if ( rc )
 hvm_unmap_ioreq_gfn(s, buf);
@@ -309,10 +309,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
 domain_crash(d);
 clear_page(iorp->va);
@@ -324,12 +324,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
 int rc;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return 0;
 
 clear_page(iorp->va);
 
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
 _mfn(page_to_mfn(iorp->page)), 0);
 if ( rc == 0 )
 paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -590,8 +590,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
 INIT_LIST_HEAD(>ioreq_vcpu_list);
 spin_lock_init(>bufioreq_lock);
 
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
 
 rc = hvm_ioreq_server_alloc_rangesets(s, id);
 if ( rc )
@@ -757,11 +757,11 @@ int 

[Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

[Paul Durrant]

...to allow the calling domain to prevent translation of specified l1e
value.

Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_translate set in its paging mode and, if it does, assumes that the
the pfn value in the l1e is a gfn rather than an mfn.

To allow PV tools domain to map mfn values from a previously issued
HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way
to tell HYPERVISOR_mmu_update that the specific l1e value does not
require translation regardless of the paging mode of foreign_dom. This
patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE,
which has the same semantics as MMU_NORMAL_PT_UPDATE except that the
paging mode of foreign_dom is ignored and the l1e value is used verbatim.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v13:
 - Re-base.

v8:
 - New in this version, replacing "allow a privileged PV domain to map
   guest mfns".
---
 xen/arch/x86/mm.c| 13 -
 xen/include/public/xen.h | 12 +---
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2656eb181a..4428b7c2d2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1881,9 +1881,10 @@ void page_unlock(struct page_info *page)
 
 /* Update the L1 entry at pl1e to new value nl1e. */
 static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
-unsigned long gl1mfn, int preserve_ad,
+unsigned long gl1mfn, unsigned int cmd,
 struct vcpu *pt_vcpu, struct domain *pg_dom)
 {
+bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD);
 l1_pgentry_t ol1e;
 struct domain *pt_dom = pt_vcpu->domain;
 int rc = 0;
@@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t 
nl1e,
 }
 
 /* Translate foreign guest address. */
-if ( paging_mode_translate(pg_dom) )
+if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
+ paging_mode_translate(pg_dom) )
 {
 p2m_type_t p2mt;
 p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
@@ -3592,6 +3594,7 @@ long do_mmu_update(
  */
 case MMU_NORMAL_PT_UPDATE:
 case MMU_PT_UPDATE_PRESERVE_AD:
+case MMU_PT_UPDATE_NO_TRANSLATE:
 {
 p2m_type_t p2mt;
 
@@ -3651,8 +3654,7 @@ long do_mmu_update(
 {
 case PGT_l1_page_table:
 rc = mod_l1_entry(va, l1e_from_intpte(req.val), mfn,
-  cmd == MMU_PT_UPDATE_PRESERVE_AD, v,
-  pg_owner);
+  cmd, v, pg_owner);
 break;
 case PGT_l2_page_table:
 rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn,
@@ -3927,7 +3929,8 @@ static int __do_update_va_mapping(
 goto out;
 }
 
-rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), 0, v, pg_owner);
+rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), MMU_NORMAL_PT_UPDATE, v,
+  pg_owner);
 
 page_unlock(gl1pg);
 put_page(gl1pg);
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 308109f176..fb1df8f293 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -268,6 +268,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
  *
+ * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE:
+ * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD
+ * page tables.
+ *
  * @val is usually the machine frame number along with some attributes.
  * The attributes by default follow the architecture defined bits. Meaning that
  * if this is a X86_64 machine and four page table layout is used, the layout
@@ -334,9 +338,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
  *
  * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
  */
-#define MMU_NORMAL_PT_UPDATE  0 /* checked '*ptr = val'. ptr is MA.  */
-#define MMU_MACHPHYS_UPDATE   1 /* ptr = MA of frame to modify entry for */
-#define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */
+#define MMU_NORMAL_PT_UPDATE   0 /* checked '*ptr = val'. ptr is MA.  
*/
+#define MMU_MACHPHYS_UPDATE1 /* ptr = MA of frame to modify entry for 
*/
+#define MMU_PT_UPDATE_PRESERVE_AD  2 /* atomically: *ptr = val | (*ptr&(A|D)) 
*/
+#define 

[Xen-devel] [PATCH v14 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Paul Durrant]

A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.

It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.

Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.

Some function return values are changed by this patch: Specifically, in
the case where the id of the default ioreq server is passed in, -EOPNOTSUPP
is now returned rather than -ENOENT.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 

v10:
 - modified FOR_EACH... macro as suggested by Jan.
 - check for NULL in IS_DEFAULT macro as suggested by Jan.

v9:
 - modified FOR_EACH... macro as requested by Andrew.

v8:
 - Addressed various comments from Jan.

v7:
 - Fixed assertion failure found in testing.

v6:
 - Updated according to comments made by Roger on v4 that I'd missed.

v5:
 - Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server()
   functions to avoid possible double-evaluation issues.

v4:
 - Introduced more helper macros and relocated them to the top of the
   code.

v3:
 - New patch (replacing "move is_default into struct hvm_ioreq_server") in
   response to review comments.
---
 xen/arch/x86/hvm/ioreq.c | 502 +++
 xen/include/asm-x86/hvm/domain.h |  10 +-
 2 files changed, 245 insertions(+), 267 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d5afe20cc8..da31918bb1 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -33,6 +33,37 @@
 
 #include 
 
+static void set_ioreq_server(struct domain *d, unsigned int id,
+ struct hvm_ioreq_server *s)
+{
+ASSERT(id < MAX_NR_IOREQ_SERVERS);
+ASSERT(!s || !d->arch.hvm_domain.ioreq_server.server[id]);
+
+d->arch.hvm_domain.ioreq_server.server[id] = s;
+}
+
+#define GET_IOREQ_SERVER(d, id) \
+(d)->arch.hvm_domain.ioreq_server.server[id]
+
+static struct hvm_ioreq_server *get_ioreq_server(const struct domain *d,
+ unsigned int id)
+{
+if ( id >= MAX_NR_IOREQ_SERVERS )
+return NULL;
+
+return GET_IOREQ_SERVER(d, id);
+}
+
+#define IS_DEFAULT(s) \
+((s) && (s) == GET_IOREQ_SERVER((s)->domain, DEFAULT_IOSERVID))
+
+/* Iterate over all possible ioreq servers */
+#define FOR_EACH_IOREQ_SERVER(d, id, s) \
+for ( (id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \
+if ( !(s = GET_IOREQ_SERVER(d, id)) ) \
+continue; \
+else
+
 static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v)
 {
 shared_iopage_t *p = s->ioreq.va;
@@ -47,10 +78,9 @@ bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
+unsigned int id;
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -127,10 +157,9 @@ bool handle_hvm_io_completion(struct vcpu *v)
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 struct hvm_ioreq_server *s;
 enum hvm_io_completion io_completion;
+unsigned int id;
 
-  list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
@@ -243,13 +272,12 @@ static int hvm_map_ioreq_page(
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
+unsigned int id;
 bool found = false;
 
 spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
 
-list_for_each_entry ( s,
-  >arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 if ( (s->ioreq.va && s->ioreq.page == page) ||
  (s->bufioreq.va && s->bufioreq.page == page) )
@@ -302,7 +330,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +359,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( IS_DEFAULT(s) )
 

[Xen-devel] [xen-unstable-smoke test] 116621: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7f080956e9eed821fd42013bef11c1a2873fbeba
baseline version:
 xen  345bb9cd634421f50b732d4f9c89a649a7a1d0db

Last test of basis   116587  2017-11-27 17:01:48 Z0 days
Testing same since   116621  2017-11-28 13:21:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Julien Grall 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   345bb9c..7f08095  7f080956e9eed821fd42013bef11c1a2873fbeba -> smoke

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

[Xen-devel] [linux-linus test] 116592: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 115643
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 115643
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 115643
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 115643
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 115643
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 115643
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt-qcow2  7 xen-bootfail REGR. vs. 115643
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 115643
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
115643
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 115643
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 115643
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 115643
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 115643
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 115643
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 115643
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 115643
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 115643
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 115643

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-saverestore fail in 116577 pass 
in 116592
 test-amd64-amd64-xl   7 xen-boot   fail pass in 116577
 test-armhf-armhf-examine  6 xen-installfail pass in 116577
 test-amd64-amd64-examine  8 reboot fail pass in 116577

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 115643

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115643
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-libvirt 13 

Re: [Xen-devel] [PATCH v4 1/7] x86/msr: add Raw and Host domain policies

[Jan Beulich]

>>> On 18.10.17 at 10:27,  wrote:
> Raw policy contains the actual values from H/W MSRs. PLATFORM_INFO msr
> needs to be read again because probe_intel_cpuid_faulting() records
> the presence of X86_FEATURE_CPUID_FAULTING but not the presence of msr
> itself (if cpuid faulting is not available).

It would be nice if this information could be propagated to avoid
the second read - I really dislike the traces such failed reads leave
in logs; at the first glance this always looks as if something was
wrong.

Apart from this the patch looks fine.

Jan


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

[Xen-devel] [PATCH] xen/arm: domain_builder: irq sanity check logic fix

[Stewart Hildebrand]

It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.

Signed-off-by: Stewart Hildebrand 
---
 xen/arch/arm/domain_build.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c74f4dd..f50f8b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -501,9 +501,10 @@ static void set_interrupt_ppi(gic_interrupt_t interrupt, 
unsigned int irq,
 {
 __be32 *cells = interrupt;
 
-BUG_ON(irq < 16 && irq >= 32);
+BUG_ON(irq < 16);
+BUG_ON(irq >= 32);
 
-/* See linux Documentation/devictree/bindings/arm/gic.txt */
+/* See linux 
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
 dt_set_cell(, 1, 1); /* is a PPI */
 dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
 dt_set_cell(, 1, (cpumask << 8) | level);
-- 
2.7.4

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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

[Jan Beulich]

>>> On 28.11.17 at 13:41,  wrote:
> On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
>> >>> On 27.11.17 at 16:41,  wrote:
>> > If it is possible we would like to have the Xen image higher than the
>> > booloader put it and certainly do not overwrite the Xen code and data
>> > during copy/relocation. Otherwise the Xen may crash silently at boot.
>>
>> Is this something that you've actually observed happening? I'd be
>> curious about the particular numbers if so.
> 
> We were hit by the issue in OVS Xen 4.4 with my earlier version of
> EFI/Multiboot2 patches. Initially its implementation allowed relocation
> of Xen even if it was relocated by the bootloader. This led to the
> crashes on some new Oracle machines because copy destination partially
> overlapped with the end of current/initial Xen image placement.
> 
> After some discussion here we decided to disable Xen relocation in my
> EFI/Multiboot2 upstream patches if the booloader did the work for us.
> Though one case is still not covered. If Xen is not relocated by the
> booloader then it tries to do that by itself. If all RAM regions above
> currently occupied one are unsuitable for relocation then Xen tries move
> itself higher in it. And if (end - reloc_size + XEN_IMG_OFFSET) goes
> below _end then copy/relocation destination overlaps, at least partially,
> with its source.
> 
> I can agree that this should not happen on todays machines very often.
> If at all. It is rather unusual to not have usable RAM regions above
> ~5 MiB nowadays. Though I think that we should at least consider putting
> such safety measure here. Otherwise Xen may crash mysteriously without
> any stack trace. So, as you may imagine it is very confusing and impairs
> further debugging. However, due to rarity of the issue I am not going to
> insist very strongly here.

I don't mind taking care of this case, as long as everything is
being properly described.

>> > Signed-off-by: Daniel Kiper 
>> > ---
>> >  xen/arch/x86/setup.c |8 +++-
>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> > index 32bb02e..be91d34 100644
>> > --- a/xen/arch/x86/setup.c
>> > +++ b/xen/arch/x86/setup.c
>> > @@ -960,7 +960,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> >  }
>> >  else
>> >  end = 0;
>> > -if ( end > s )
>> > +
>> > +/*
>> > + * Is the region size greater than zero?
>>
>> Why "greater than zero"?
> 
> end > s?

Oh, I had wrongly assumed the comment was meant to cover only
the addition you're making to the condition.

>> > + * Does the region begins above or at the
>> > + * end of current Xen image placement?
>> > + */
>> > +if ( end > s && (end - reloc_size >= _end - _start) )
>>
>> And how does this added condition effect Xen only being moved
>> upwards? _end - _start after all is only the Xen image size, with
>> no consideration of its position. Plus I think you really mean
>> __2M_rwdata_end instead of _end.
> 
> OK, we have below:
> 
> [...]
> 
> e = end - reloc_size;
> 
> [...]
> 
> move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
> 
> So, we have: e + XEN_IMG_OFFSET >= XEN_IMG_OFFSET + _end - _start
> 
> We can drop XEN_IMG_OFFSET, so we have: e >= _end - _start
> 
> However, we cannot use "e" in the condition, so we have:
>   end - reloc_size >= _end - _start

Okay, so this implies an original base address of zero. In that case,
however, we can't possibly move Xen downwards; looks like I've
misunderstood the title/description: You're really worried about an
overlap of the regions. From description and comment I was getting
the impression that the goal would be to cover more cases (including
ones where Xen wasn't loaded at the lowest possible address).
Could you try to make this more clear?

Furthermore I'm not convinced the condition needs to be as strict
as you make it now: As long as move_memory() can deal with
overlapping areas, a partial overlap looks to be okay. That would
allow for more cases where Xen does actually get moved even
with very little memory.

Another option is to consider not moving Xen based on other
criteria: The main goal here is to free up memory below 16Mb. If
the machine has no memory above 16Mb, moving Xen around
won't do any good in this regard.

Jan

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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

[Daniel Kiper]

On Tue, Nov 28, 2017 at 07:02:01AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 14:53,  wrote:
> > On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 13:47,  wrote:
> >> > Then all cases should be covered.
> >>
> >> I don't think that's going to be enough: Once Xen gets moved,
> >> the area to exclude needs to be updated too.
> >
> > If the Xen is relocated by the booloader then the Xen does not do relocation
> > itself again. So, it should work.
>
> Then let me reformulate this into "... the area to exclude needs to
> be set".

Oh... You mean consider_modules() with efi_enabled(EFI_LOADER) in the
same patch. Right, we can replace "efi_enabled(EFI_LOADER)" with
"!!xen_phys_start" then.

Daniel

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

Re: [Xen-devel] [PATCH] arm64: ITS: fix cacheability adjustment

[Andre Przywara]

Hi,

On 16/11/17 12:02, Andre Przywara wrote:
> If the host GICv3 redistributor reports that the pending table cannot
> use shareable memory, we try to drop the cacheability attributes as
> well. However we fail horribly in doing computer science 101 bit
> masking, effectively clearing the whole register instead of just a few
> bits.
> Fix this by removing the one redundant masking operation and adding the
> magic negation for the actually needed other operation.
> 
> Reported-by: Manish Jaggi 

Manish, can you please test this patch and confirm that it works?
Also how does the bug manifest for you?

Julien, Stefano: Are there any objections against taking this patch for
4.10? This was introduced with the ITS emulation.

Cheers,
Andre.

> Signed-off-by: Andre Przywara 
> ---
> Julien,
> 
> can we have this still for 4.10, please? Seems like an obvious bug to me.
> 
> Cheers,
> Andre
> 
>  xen/arch/arm/gic-v3-lpi.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index c3474f5434..84582157b8 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -359,8 +359,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base)
>  /* If the hardware reports non-shareable, drop cacheability as well. */
>  if ( !(table_reg & GICR_PENDBASER_SHAREABILITY_MASK) )
>  {
> -table_reg &= GICR_PENDBASER_SHAREABILITY_MASK;
> -table_reg &= GICR_PENDBASER_INNER_CACHEABILITY_MASK;
> +table_reg &= ~GICR_PENDBASER_INNER_CACHEABILITY_MASK;
>  table_reg |= GIC_BASER_CACHE_nC << 
> GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
>  
>  writeq_relaxed(table_reg, rdist_base + GICR_PENDBASER);
> 

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

[Xen-devel] [qemu-mainline test] 116610: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
116533

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

version targeted for testing:
 qemuu5e19aed59ab48ca3c7f1e2da203eed27b91bef2d
baseline version:
 qemuue7b47c22e2df14d55e3e4426688c929bf8e3f7fb

Last test of basis   116533  2017-11-25 17:34:19 Z2 days
Testing same since   116583  2017-11-27 13:48:20 Z1 days3 attempts


People who touched revisions under test:
  David Gibson 
  Peter Maydell 
  Suraj Jitindar Singh 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

[Jan Beulich]

>>> On 28.11.17 at 14:53,  wrote:
> On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 13:47,  wrote:
>> > Then all cases should be covered.
>>
>> I don't think that's going to be enough: Once Xen gets moved,
>> the area to exclude needs to be updated too.
> 
> If the Xen is relocated by the booloader then the Xen does not do relocation
> itself again. So, it should work.

Then let me reformulate this into "... the area to exclude needs to
be set".

Jan


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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

[Daniel Kiper]

On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 13:47,  wrote:
> > On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 12:32,  wrote:
> >> > I have a feeling that you can trigger this also when xen.efi
> >> > is launched directly from EFI. However, this may require some
> >> > fiddling with crashkernel values.
> >>
> >> I don't think so, no - that case was specifically fixed already
> >> (I've pointed at that commit in another sub-thread).
> >
> > Ugh... Right, it looks that I misread the patch. Anyway, it seems to
> > me that is easy to fix. We should change line xen/arch/x86/setup.c:907
> >
> > if ( efi_enabled(EFI_LOADER) )
> >
> > to
> >
> > if ( !xen_phys_start )
>
> But xen_phys_start is non-zero when efi_enabled(EFI_LOADER).

Err... Copy-paste error. Of course I thought about "if ( xen_phys_start )".
Then this covers EFI_LOADER case and relocation by the bootloader.

> > Then all cases should be covered.
>
> I don't think that's going to be enough: Once Xen gets moved,
> the area to exclude needs to be updated too.

If the Xen is relocated by the booloader then the Xen does not do relocation
itself again. So, it should work.

Daniel

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

[Xen-devel] [distros-debian-snapshot test] 72497: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail like 72475
 test-amd64-amd64-i386-daily-netboot-pygrub 10 debian-di-install fail like 72475
 test-amd64-i386-amd64-daily-netboot-pygrub 10 debian-di-install fail like 72475
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
72475
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail like 
72475
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 72475
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
72475
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
72475

baseline version:
 flight   72475

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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] x86/setup: do not relocate below the end of current Xen image placement

[Daniel Kiper]

On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
> >>> On 27.11.17 at 16:41,  wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation. Otherwise the Xen may crash silently at boot.
>
> Is this something that you've actually observed happening? I'd be
> curious about the particular numbers if so.

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

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

I can agree that this should not happen on todays machines very often.
If at all. It is rather unusual to not have usable RAM regions above
~5 MiB nowadays. Though I think that we should at least consider putting
such safety measure here. Otherwise Xen may crash mysteriously without
any stack trace. So, as you may imagine it is very confusing and impairs
further debugging. However, due to rarity of the issue I am not going to
insist very strongly here.

> > Signed-off-by: Daniel Kiper 
> > ---
> >  xen/arch/x86/setup.c |8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 32bb02e..be91d34 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -960,7 +960,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  }
> >  else
> >  end = 0;
> > -if ( end > s )
> > +
> > +/*
> > + * Is the region size greater than zero?
>
> Why "greater than zero"?

end > s?

> > + * Does the region begins above or at the
> > + * end of current Xen image placement?
> > + */
> > +if ( end > s && (end - reloc_size >= _end - _start) )
>
> And how does this added condition effect Xen only being moved
> upwards? _end - _start after all is only the Xen image size, with
> no consideration of its position. Plus I think you really mean
> __2M_rwdata_end instead of _end.

OK, we have below:

[...]

e = end - reloc_size;

[...]

move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);

So, we have: e + XEN_IMG_OFFSET >= XEN_IMG_OFFSET + _end - _start

We can drop XEN_IMG_OFFSET, so we have: e >= _end - _start

However, we cannot use "e" in the condition, so we have:
  end - reloc_size >= _end - _start

> Also as a more general remark: While we dislike too long lines,
> too short ones aren't very nice either. Without trying it out I
> can't even be sure the whole comment wouldn't perhaps fit on
> two lines instead of the three it uses right now.

Wilco!

> Finally - please use parentheses in expressions consistently.

Wilco!

Daniel

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Jan Beulich]

>>> On 28.11.17 at 12:58,  wrote:
>>  -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 28 November 2017 11:31
>> To: 'Jan Beulich' 
>> Cc: Andrew Cooper ; Julien Grall
>> ; xen-devel 
>> Subject: Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal
>> and extern emulation
>> 
>> > -Original Message-
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 28 November 2017 11:26
>> > To: Paul Durrant 
>> > Cc: Julien Grall ; Andrew Cooper
>> > ; xen-devel > > de...@lists.xenproject.org>
>> > Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
>> > emulation
>> >
>> > >>> On 28.11.17 at 12:06,  wrote:
>> > > Yes, it appears that mmio_retry is only set when the underlying
>> emulation
>> > > returned X86EMUL_OKAY but not all reps were completed. If the
>> > underlying
>> > > emulation did not return X86EMUL_RETRY then I can't figure out why
>> > > vio->io_completion should need to be set to anything other than
>> > > HVMIO_no_completion since any other return value indicates there
>> should
>> > be
>> > > nothing pending.
>> >
>> > So am I getting it right that you're suggesting to remove the
>> > mmio_retry part of the condition in hvm_emulate_one_insn()?
>> > That looks like it might work (I was previously only considering
>> > to get rid of mmio_retry altogether, and that didn't look like a
>> > viable route).
>> 
>> Yes, that's what I'm suggesting. I really can't see why it is needed. It 
> could
>> have been a mistake in my original patches or a semantic change in a
>> subsequent patch, but it certainly looks wrong in current context.
>> Andrew has just sent me his xtf repro so I'll give the change a go with 
> that.
> 
> Yes, this patch fixed the problem for me. I'll do some more tests to check 
> for collateral damage now... If it's all good, do you want me to submit it or 
> do you want to send it as a v2 of your patch?

It's yours, so please submit it (perhaps nevertheless as v2). Feel
free to add my R-b right away if no other change turns out
necessary.

Jan


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

[Xen-devel] Xen Security Advisory 247 - Missing p2m error checking in PoD code

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-247
  version 2

 Missing p2m error checking in PoD code

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Certain actions require modification of entries in a guest's P2M
(Physical-to-Machine) table.  When large pages are in use for this
table, such an operation may incur a memory allocation (to replace a
large mapping with individual smaller ones).  If this allocation
fails, the p2m_set_entry() function will return an error.

Unfortunately, several places in the populate-on-demand code don't
check the return value of p2m_set_entry() to see if it succeeded.

In some cases, the operation was meant to remove an entry from the p2m
table.  If this removal fails, a malicious guest may engineer that the
page be returned to the Xen free list, making it available to be
allocated to another domain, while it retains a writable mapping to
the page.

In other cases, the operation was meant to remove special
populate-on-demand entries; if this removal fails, the internal
accounting becomes inconsistent and may eventually hit a BUG().

The allocation involved comes from a separate pool of memory created
when the domain is created; under normal operating conditions it never
fails, but a malicious guest may be able to engineer situations where
this pool is exhausted.

IMPACT
==

An unprivileged guest can retain a writable mapping of freed memory.
Depending on how this page is used, it could result in either an
information leak, or full privilege escalation.

Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
causing a clean crash - ie, host-wide denial-of-service (DoS).

VULNERABLE SYSTEMS
==

All systems from Xen 3.4 are vulnerable.

Only x86 systems are vulnerable.  ARM is not vulnerable.

x86 PV VMs cannot leverage the vulnerability.

Only systems with 2MiB or 1GiB HAP pages enabled are vulnerable.

The vulnerability is largely restricted to HVM guests which have been
constructed in Populate-on-Demand mode (i.e. with memory < maxmem):

x86 HVM domains without PoD (i.e. started with memory == maxmem, or
without mentioning "maxmem" in the guest config file) also cannot
leverage the vulnerability, in recent enough Xen versions:
  4.8.x and later: all versions safe if PoD not configured
  4.7.x: 4.7.1 and later safe if PoD not configured
  4.6.x: 4.6.4 and later safe if PoD not configured
  4.5.x: 4.5.4 and later safe if PoD not configured
  4.4.x and earlier: all versions vulnerable even if PoD not configured

The commit required to prevent this vulnerability when PoD
not configured is 2a99aa99fc84a45f505f84802af56b006d14c52e
  xen/physmap: Do not permit a guest to populate PoD pages for itself
and the corresponding backports.

MITIGATION
==

Running only PV guests will avoid this issue.

Running HVM guests only in non-PoD mode (maxmem == memory) will also
avoid this issue.  NOTE: In older releases of Xen, an HVM guest can
create PoD entries itself; so this mitigation will not be effective.

Specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will
also avoid the vulnerability.

Alternatively, running all x86 HVM guests in shadow mode will also
avoid this vulnerability.  (For example, by specifying "hap=0" in the
xl domain configuration file.)

CREDITS
===

This issue was discovered by George Dunlap of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa247/*.patch   xen-unstable
xsa247-4.9/*.patch   Xen 4.9.x
xsa247-4.8/*.patch   Xen 4.8.x
xsa247-4.7/*.patch   Xen 4.7.x
xsa247-4.6/*.patch   Xen 4.6.x
xsa247-4.5/*.patch   Xen 4.5.x

$ sha256sum xsa247* xsa247*/*
e8fc454c35f429ab60b94c0e812f86fd2b3b37edfff2bfdcc13a7e13ebc2efbe  xsa247.meta
59e977d81ad85c25572b79db48d62b4f040026e88f51fe61051b7d30e97fad06  
xsa247-4.5/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
6221f5fc7899253888a1711e83436f1b8ddc51046ec920d83b7ea2f4266d13f7  
xsa247-4.5/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
f54c4984731f9138e522685e98359a0bb409146091fedb8b7beaac48b3460c22  
xsa247-4.6/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
258aaa76e164d70fbfead9de1370577c328dff78c09b81ac7b708fd5c530859a  
xsa247-4.6/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
85f0d5f3940bb27f84867b9ac227636a786519dfc1b35ad82f402f9c044ecac9  
xsa247-4.7/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
8f0d45b617e0b4c0c1ff490e84c6415f1444696d2afce09eeaa970fbedb8f4c3  
xsa247-4.7/0002-p2m-Check-return-value-of-p2m_set_entry-when-decreas.patch
580771a125aa577ff4c7607679ef5d8d6c668446f4573bf11e4fe6829d02d157  
xsa247-4.8/0001-p2m-Always-check-to-see-if-removing-a-p2m-entry-actu.patch
f88d252305d8229374f3fe25bae3c9ea165acab28be9908a1a9a816ae85170ac  

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Am 28.11.2017 um 11:53 schrieb Jan Beulich:

On 28.11.17 at 11:17,  wrote:

Am 28.11.2017 um 10:46 schrieb Jan Beulich:

On 28.11.17 at 10:12,  wrote:

In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel in the first place.

How would the BIOS know what the OS does or plans to do?

As far as I know the ACPI BIOS should work directly with the register
content.

So when we update the register content to enable the MMIO decoding the
BIOS should know that as well.

I'm afraid I don't follow: During memory hotplug, surely you don't
expect the BIOS to do a PCI bus scan? Plus even if it did, it would
be racy - some device could, at this very moment, have memory
decoding disabled, just for the OS to re-enable it a millisecond
later. Yet looking at BAR values is meaningless when memory
decode of a device is disabled.


No, sorry you misunderstood me. The PCI bus is not even involved here.

In AMD Family CPUs you have four main types of address space routed by 
the NB:

1.  Memory space targeting system DRAM.
2.  Memory space targeting IO (MMIO).
3.  IO space.
4.  Configuration space.

See section "2.8.2 NB Routing" in the BIOS and Kernel Developer’s Guide 
(https://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf).


Long story short you have fix addresses for configuration and legacy IO 
(VGA for example) and then configurable memory space for DRAM and MMIO.


What the ACPI BIOS does (or at least should do) is taking a look at the 
registers to find space during memory hotplug.


Now in theory the MMIO space should be configurable by similar ACPI BIOS 
functions, but unfortunately most BIOS doesn't enable that function 
because it can break some older Windows versions.


So what we do here is just what the BIOS should have provided in the 
first place.



I think
it's the other way around - the OS needs to avoid using any regions
for MMIO which are marked as hotpluggable in SRAT.

I was under the impression that this is exactly what
acpi_numa_memory_affinity_init() does.

Perhaps, except that (when I last looked) insufficient state is
(was) being recorded to have that information readily available
at the time MMIO space above 4Gb needs to be allocated for
some device.


That was also my concern, but in the most recent version I'm 
intentionally doing this fixup very late after all the PCI setup is 
already done.


This way the extra address space is only available for devices which are 
added by PCI hotplug or for resizing BARs on the fly (which is the use 
case I'm interested in).



Since there is
no vNUMA yet for Xen Dom0, that would need special handling.

I think that the problem is rather that SRAT is NUMA specific and if I'm
not totally mistaken the content is ignored when NUMA support isn't
compiled into the kernel.

When Xen steals some memory from Dom0 by hocking up itself into the e820
call then I would say the cleanest way is to report this memory in e820
as reserved as well. But take that with a grain of salt, I'm seriously
not a Xen expert.

The E820 handling in PV Linux is all fake anyway - there's a single
chunk of memory given to a PV guest (including Dom0), contiguous
in what PV guests know as "physical address space" (not to be
mixed up with "machine address space", which is where MMIO
needs to be allocated from). Xen code in the kernel then mimics
an E820 matching the host one, moving around pieces of memory
in physical address space if necessary.


Good to know.


Since Dom0 knows the machine E820, MMIO allocation shouldn't
need to be much different there from the non-Xen case.


Yes, completely agree.

I think even if we don't do MMIO allocation with this fixup letting the 
kernel in Dom0 know which memory/address space regions are in use is 
still a good idea.


Otherwise we will run into exactly the same problem when we do the MMIO 
allocation with an ACPI method and that is certainly going to come in 
the next BIOS generations because Microsoft is pushing for it.


Regards,
Christian.



Jan




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

Re: [Xen-devel] [PATCH] x86/setup: do not relocate below the end of current Xen image placement

[Daniel Kiper]

On Mon, Nov 27, 2017 at 04:58:52PM +, Andrew Cooper wrote:
> On 27/11/17 15:41, Daniel Kiper wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation. Otherwise the Xen may crash silently at boot.
> >
> > Signed-off-by: Daniel Kiper 
>
> Actually, there is a second related bug which I've only just got to the
> bottom of, and haven't had time to fix yet.
>
> (XEN) Bootloader: GRUB 2.02
> (XEN) Command line: hvm_fep com1=115200,8n1 console=com1,vga
> dom0_mem=2048M,max:2048M watchdog ucode=scan dom0_max_vcpus=8
> crashkernel=192M,below=4G
> (XEN) Xen image load base address: 0xaba0
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
> (XEN)  EDID info not retrieved because no DDC retrieval method detected
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 0009bc00 (usable)
> (XEN)  0009bc00 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - ac209000 (usable)
> (XEN)  ac209000 - aeb99000 (reserved)
> (XEN)  aeb99000 - aeb9d000 (ACPI NVS)
> (XEN)  aeb9d000 - aecd1000 (reserved)
> (XEN)  aecd1000 - aecd4000 (ACPI NVS)
> (XEN)  aecd4000 - aecf5000 (reserved)
> (XEN)  aecf5000 - aecf6000 (ACPI NVS)
> (XEN)  aecf6000 - aed24000 (reserved)
> (XEN)  aed24000 - aef2f000 (ACPI NVS)
> (XEN)  aef2f000 - aefed000 (ACPI data)
> (XEN)  aefed000 - af00 (usable)
> (XEN)  af00 - b000 (reserved)
> (XEN)  f800 - fc00 (reserved)
> (XEN)  fec0 - fec01000 (reserved)
> (XEN)  fed19000 - fed1a000 (reserved)
> (XEN)  fed1c000 - fed2 (reserved)
> (XEN)  fee0 - fee01000 (reserved)
> (XEN)  ff40 - 0001 (reserved)
> (XEN)  0001 - 00085000 (usable)
> (XEN) Kdump: DISABLED (failed to reserve 192MB (196608kB) at 0xa020)
> (XEN) ACPI: RSDP 000F0410, 0024 (r2 INTEL )
>
> When booting with Grub2 capable of locating Xen at its preferred
> location, the calculation for the kexec region fails, because the
> current location of Xen isn't taken into account.
>
> The end of the chosen kexec region (0xa020 + 0x0c00) overlaps
> with the bottom of the Xen image.

I have a feeling that you can trigger this also when xen.efi
is launched directly from EFI. However, this may require some
fiddling with crashkernel values.

Daniel

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Jan Beulich]

>>> On 28.11.17 at 12:06,  wrote:
> Yes, it appears that mmio_retry is only set when the underlying emulation 
> returned X86EMUL_OKAY but not all reps were completed. If the underlying 
> emulation did not return X86EMUL_RETRY then I can't figure out why 
> vio->io_completion should need to be set to anything other than 
> HVMIO_no_completion since any other return value indicates there should be 
> nothing pending.

So am I getting it right that you're suggesting to remove the
mmio_retry part of the condition in hvm_emulate_one_insn()?
That looks like it might work (I was previously only considering
to get rid of mmio_retry altogether, and that didn't look like a
viable route).

Jan


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

[Xen-devel] [seabios test] 116603: regressions - FAIL

[osstest service owner]

flight 116603 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116603/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  df46d10c8a7b88eb82f3ceb2aa31782dee15593d
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   24 days
Failing since115733  2017-11-10 17:19:59 Z   17 days   31 attempts
Testing same since   116211  2017-11-16 00:20:45 Z   12 days   21 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Signed-off-by: Kevin O'Connor 

commit 9ce6778f08c632c52b25bc8f754291ef18710d53
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:16:36 2017 -0500

docs: Add sercon-port to Runtime_config.md documentation

Signed-off-by: Kevin O'Connor 

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Christian König]

Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky:

On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:


On 11/23/2017 03:11 AM, Christian König wrote:

Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:

On 11/22/2017 11:54 AM, Christian König wrote:

Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:

On 11/22/2017 05:09 AM, Christian König wrote:

Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:

On 11/21/2017 08:34 AM, Christian König wrote:

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for
the
root window.

The second is a workaround for your board. It simply checks if
there
is exactly one Processor Function to apply this fix on.

Both are based on linus current master branch. Please test if they
fix
your issue.

Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?

I still haven't understood what you actually did with Xen.

When you used PCI pass through with those devices then you have
made a
major configuration error.

When the problem happened on dom0 then the explanation is most
likely
that some PCI device ended up in the configured space, but the
routing
was only setup correctly on one CPU socket.

The problem is that dom0 can be (and was in my case() booted with
less
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure
that
memory for MMIO and the system hang.

And so my guess is that this patch will break dom0 on a single-socket
system as well.

Oh, thanks!

I've thought about that possibility before, but wasn't able to find a
system which actually does that.

May I ask why the rest of the memory isn't reported to the OS?

That memory doesn't belong to the OS (dom0), it is owned by the
hypervisor.


Sounds like I can't trust Linux resource management and probably need
to read the DRAM config to figure things out after all.

My question is whether what you are trying to do should ever be done
for
a guest at all (any guest, not necessarily Xen).

The issue is probably that I don't know enough about Xen: What
exactly is dom0? My understanding was that dom0 is the hypervisor,
but that seems to be incorrect.

The issue is that under no circumstances *EVER* a virtualized guest
should have access to the PCI devices marked as "Processor Function"
on AMD platforms. Otherwise it is trivial to break out of the
virtualization.

When dom0 is something like the system domain with all hardware
access then the approach seems legitimate, but then the hypervisor
should report the stolen memory to the OS using the e820 table.

When the hypervisor doesn't do that and the Linux kernel isn't aware
that there is memory at a given location mapping PCI space there will
obviously crash the hypervisor.

Possible solutions as far as I can see are either disabling this
feature when we detect that we are a Xen dom0, scanning the DRAM
settings to update Linux resource handling or fixing Xen to report
stolen memory to the dom0 OS as reserved.

Opinions?

You are right, these functions are not exposed to a regular guest.

I think for dom0 (which is a special Xen guest, with additional
privileges) we may be able to add a reserved e820 region for host
memory that is not assigned to dom0. Let me try it on Monday (I am out
until then).


One thing I realized while looking at solution for Xen dom0 is that this
patch may cause problems for memory hotplug.


Good point. My assumption was that when you got an BIOS which can handle 
memory hotplug then you also got an BIOS which doesn't need this fixup. 
But I've never validated that assumption.



What happens if new memory
is added to the system and we have everything above current memory set
to MMIO?


In theory the BIOS would search for address space and won't find 
anything, so the hotplug operation should fail even before it reaches 
the kernel in the first place.


In practice I think that nobody ever tested if that works correctly. So 
I'm pretty sure the system would just crash.


How about the attached patch? It limits the newly added MMIO space to 
the upper 256GB of the address space. That should still be enough for 
most devices, but we avoid both issues with Xen dom0 as most likely 
problems with memory hotplug as well.


Christian.



-boris



>From 586bd9d67ebb6ca48bd0a6b1bd9203e94093cc8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Tue, 28 Nov 2017 10:02:35 +0100
Subject: [PATCH] x86/PCI: limit the size of the 64bit BAR to 256GB
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This avoids problems with Xen which hides some memory resources from the
OS and potentially also allows memory hotplug while this fixup is
enabled.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 2 +-
 1 file 

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 November 2017 11:01
> To: 'Jan Beulich' 
> Cc: Andrew Cooper ; Julien Grall
> ; xen-devel 
> Subject: Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal
> and extern emulation
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 28 November 2017 10:40
> > To: Paul Durrant 
> > Cc: Julien Grall ; Andrew Cooper
> > ; xen-devel  > de...@lists.xenproject.org>
> > Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> > emulation
> >
> > >>> On 28.11.17 at 11:22,  wrote:
> > > It would definitely be good to only reset io_completion when it is clear
> > > that handle_hvm_io_completion() is not going to be called (i.e. for
> > > internally handled I/O)
> >
> > Where would you suggest to do that? These two ...
> >
> > > and perhaps even add ASSERTs in _hvm_emulate_one()
> > > and handle_pio().
> >
> > ... sit down the call tree from handle_hvm_io_completion(). Plus
> > internal vs external isn't distinguishable in _hvm_emulate_one()
> > afaict (neither on the way in nor on the way out).
> 
> Whether the emulation is being handed internally or externally should be
> apparent on the way out because that's what
> hvm_vcpu_io_need_completion() is testing for after the call to
> hvm_emulate_one() in hvm_emulate_one_insn(). The problem is
> completion being requested if mmio_retry is set even if the former test fails,
> and I can't remember why that is. On the face of it, it looks wrong.

Yes, it appears that mmio_retry is only set when the underlying emulation 
returned X86EMUL_OKAY but not all reps were completed. If the underlying 
emulation did not return X86EMUL_RETRY then I can't figure out why 
vio->io_completion should need to be set to anything other than 
HVMIO_no_completion since any other return value indicates there should be 
nothing pending.

  Paul

> 
> > Adding
> > ASSERT()s there suggests the distinction would need to be done
> > up the call stack, yet up the call stack may only be the VM exit
> > handler. I don't think the state reset should be done in vendor-
> > specific code.
> >
> 
> I was hoping that an argument could be passed into the call stack by
> handle_hvm_io_completion() so that the lower layers would be able to
> distinguish a re-emulation from an initial call and thus be able to verify 
> state.
> Maybe that is not practical though.
> 
>   Paul
> 
> > Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:40
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel  de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
> 
> >>> On 28.11.17 at 11:22,  wrote:
> > It would definitely be good to only reset io_completion when it is clear
> > that handle_hvm_io_completion() is not going to be called (i.e. for
> > internally handled I/O)
> 
> Where would you suggest to do that? These two ...
> 
> > and perhaps even add ASSERTs in _hvm_emulate_one()
> > and handle_pio().
> 
> ... sit down the call tree from handle_hvm_io_completion(). Plus
> internal vs external isn't distinguishable in _hvm_emulate_one()
> afaict (neither on the way in nor on the way out).

Whether the emulation is being handed internally or externally should be 
apparent on the way out because that's what hvm_vcpu_io_need_completion() is 
testing for after the call to hvm_emulate_one() in hvm_emulate_one_insn(). The 
problem is completion being requested if mmio_retry is set even if the former 
test fails, and I can't remember why that is. On the face of it, it looks wrong.

> Adding
> ASSERT()s there suggests the distinction would need to be done
> up the call stack, yet up the call stack may only be the VM exit
> handler. I don't think the state reset should be done in vendor-
> specific code.
> 

I was hoping that an argument could be passed into the call stack by 
handle_hvm_io_completion() so that the lower layers would be able to 
distinguish a re-emulation from an initial call and thus be able to verify 
state. Maybe that is not practical though.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

[Juergen Gross]

On 28/11/17 11:17, Roger Pau Monné wrote:
> On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote:
>> When booted via the special PVH entry save the RSDP address set in the
>> boot information block in struct boot_params. This will enable Xen to
>> locate the RSDP at an arbitrary address.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  arch/x86/xen/enlighten_pvh.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
>> index 436c4f003e17..0175194f4236 100644
>> --- a/arch/x86/xen/enlighten_pvh.c
>> +++ b/arch/x86/xen/enlighten_pvh.c
>> @@ -71,6 +71,8 @@ static void __init init_pvh_bootparams(void)
>>   */
>>  pvh_bootparams.hdr.version = 0x212;
> 
> Shouldn't this be 0x20e, like it's set in patch 1?

I think it was meant to be 0x20c. But setting it to 0x20e in this patch
seems to be a good idea.

In the end it doesn't really matter, as hdr.version is meant to be read
by the boot loader which is already history when this code is being
executed.


Juergen

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:17
> To: Paul Durrant 
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel  de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
> 
> >>> On 28.11.17 at 11:05,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 28 November 2017 10:02
> >> >>> On 28.11.17 at 10:49,  wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 27 November 2017 08:29
> >> >> handle_hvm_io_completion() is being involved in resuming from
> requests
> >> >> sent to a device model only, while re-invocation of internally handled
> >> >> I/O which couldn't be handled in one go simply re-starts the affected
> >> >> instruction. When an internally handled split request is being followed
> >> >> by one sent to a device model, so far nothing reset vio-
> >io_completion,
> >> >> leading to an MMIO emulation attempt on the next instruction _after_
> >> the
> >> >> one succesfully sent to qemu if that one doesn't itself require
> >> >> completion handling.
> >> >>
> >> >> Since only repeated string instructions are affected, strictly speaking
> >> >> the adjustment to handle_pio() isn't needed. Do it nevertheless for
> >> >> consistency as well as to avoid the lack thereof becoming an issue in
> >> >> the future; put the main change in generic enough a place to also cover
> >> >> VMX real mode emulation.
> >> >>
> >> >> Reported-by: Andrew Cooper 
> >> >> Signed-off-by: Jan Beulich 
> >> >> ---
> >> >> It has been puzzling me for years how we could get away without
> clearing
> >> >> vio->io_completion in any more central place, i.e. other than as part of
> >> >> handling the completion.
> >> >
> >> > The idea is that, because HVMIO_no_completion is zero and thus the
> initial
> >> > value of vio->io_completion, no explicit initialization is required. If 
> >> > it is
> >> > set to anything other than that then there needs to be a call to
> >> > handle_hvm_io_completion() which will duly set it back
> >> HVMIO_no_completion.
> >> > So the question is how it is being set and why does this not result in 
> >> > the
> >> > appropriate completion call? I fear this patch is covering up a more
> >> > fundamental problem with the state model in certain cases.
> >>
> >> Well - see the patch description: vio->mmio_retry being set after an
> >> emulation means hvm_emulate_one_insn() setting ->io_completion
> >> to HVMIO_mmio_completion no matter whether the request needs to
> >> go to qemu or is being handled internally.
> >
> > Well that sounds like the problem then.
> >
> >> Internally handled requests,
> >> as explained, don't need a completion to be run, though, and it will
> >> be the exception rather than the rule that handle_hvm_io_completion()
> >> would be invoked in such a case, causing ->io_completion to be cleared
> >> again.
> >>
> >> Quite the contrary to what you say, I don't see why ->io_completion
> >> wasn't zapped the way the patch does it from the beginning. Nothing
> >> good can come from stale state being used _regardless_ of whether
> >> the most recent operation was handled externally or internally.
> >
> > Because the state should never be stale. It sounds like use of mmio_retry is
> > being overloaded and that's leading to this issue.
> 
> Looking forward to an alternative (preferably not overly intrusive)
> patch proposal then, if you dislike this one.

It would definitely be good to only reset io_completion when it is clear that 
handle_hvm_io_completion() is not going to be called (i.e. for internally 
handled I/O) and perhaps even add ASSERTs in _hvm_emulate_one() and 
handle_pio().

  Paul

> 
> Jan


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

Re: [Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

[Roger Pau Monné]

On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote:
> In case the rsdp address in struct boot_params is specified don't try
> to find the table by searching, but take the address directly as set
> by the boot loader.
> 
> Signed-off-by: Juergen Gross 
> ---
>  drivers/acpi/osl.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 3bb46cb24a99..3b25e2ad7d75 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -45,6 +45,10 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_X86
> +#include 
> +#endif
> +
>  #include "internal.h"
>  
>  #define _COMPONENT   ACPI_OS_SERVICES
> @@ -195,6 +199,10 @@ acpi_physical_address __init 
> acpi_os_get_root_pointer(void)
>   if (acpi_rsdp)
>   return acpi_rsdp;
>  #endif
> +#ifdef CONFIG_X86
> + if (boot_params.hdr.acpi_rsdp_addr)
> + return boot_params.hdr.acpi_rsdp_addr;
> +#endif

I'm struggling to figure out how was PVH getting the RSDP previously,
because that should be removed now that it's in the zero-page.

Roger.

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

[Roger Pau Monné]

On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote:
> When booted via the special PVH entry save the RSDP address set in the
> boot information block in struct boot_params. This will enable Xen to
> locate the RSDP at an arbitrary address.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/xen/enlighten_pvh.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> index 436c4f003e17..0175194f4236 100644
> --- a/arch/x86/xen/enlighten_pvh.c
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -71,6 +71,8 @@ static void __init init_pvh_bootparams(void)
>*/
>   pvh_bootparams.hdr.version = 0x212;

Shouldn't this be 0x20e, like it's set in patch 1?

Roger.

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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Jan Beulich]

>>> On 28.11.17 at 10:49,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2017 08:29
>> To: xen-devel 
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant 
>> Subject: [PATCH] x86/HVM: fix interaction between internal and extern
>> emulation
>> 
>> handle_hvm_io_completion() is being involved in resuming from requests
>> sent to a device model only, while re-invocation of internally handled
>> I/O which couldn't be handled in one go simply re-starts the affected
>> instruction. When an internally handled split request is being followed
>> by one sent to a device model, so far nothing reset vio->io_completion,
>> leading to an MMIO emulation attempt on the next instruction _after_ the
>> one succesfully sent to qemu if that one doesn't itself require
>> completion handling.
>> 
>> Since only repeated string instructions are affected, strictly speaking
>> the adjustment to handle_pio() isn't needed. Do it nevertheless for
>> consistency as well as to avoid the lack thereof becoming an issue in
>> the future; put the main change in generic enough a place to also cover
>> VMX real mode emulation.
>> 
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Jan Beulich 
>> ---
>> It has been puzzling me for years how we could get away without clearing
>> vio->io_completion in any more central place, i.e. other than as part of
>> handling the completion.
> 
> The idea is that, because HVMIO_no_completion is zero and thus the initial 
> value of vio->io_completion, no explicit initialization is required. If it is 
> set to anything other than that then there needs to be a call to 
> handle_hvm_io_completion() which will duly set it back HVMIO_no_completion. 
> So the question is how it is being set and why does this not result in the 
> appropriate completion call? I fear this patch is covering up a more 
> fundamental problem with the state model in certain cases.

Well - see the patch description: vio->mmio_retry being set after an
emulation means hvm_emulate_one_insn() setting ->io_completion
to HVMIO_mmio_completion no matter whether the request needs to
go to qemu or is being handled internally. Internally handled requests,
as explained, don't need a completion to be run, though, and it will
be the exception rather than the rule that handle_hvm_io_completion()
would be invoked in such a case, causing ->io_completion to be cleared
again.

Quite the contrary to what you say, I don't see why ->io_completion
wasn't zapped the way the patch does it from the beginning. Nothing
good can come from stale state being used _regardless_ of whether
the most recent operation was handled externally or internally.

Jan


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

Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal and extern emulation

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2017 08:29
> To: xen-devel 
> Cc: Julien Grall ; Andrew Cooper
> ; Paul Durrant 
> Subject: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
> 
> handle_hvm_io_completion() is being involved in resuming from requests
> sent to a device model only, while re-invocation of internally handled
> I/O which couldn't be handled in one go simply re-starts the affected
> instruction. When an internally handled split request is being followed
> by one sent to a device model, so far nothing reset vio->io_completion,
> leading to an MMIO emulation attempt on the next instruction _after_ the
> one succesfully sent to qemu if that one doesn't itself require
> completion handling.
> 
> Since only repeated string instructions are affected, strictly speaking
> the adjustment to handle_pio() isn't needed. Do it nevertheless for
> consistency as well as to avoid the lack thereof becoming an issue in
> the future; put the main change in generic enough a place to also cover
> VMX real mode emulation.
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> ---
> It has been puzzling me for years how we could get away without clearing
> vio->io_completion in any more central place, i.e. other than as part of
> handling the completion.

The idea is that, because HVMIO_no_completion is zero and thus the initial 
value of vio->io_completion, no explicit initialization is required. If it is 
set to anything other than that then there needs to be a call to 
handle_hvm_io_completion() which will duly set it back HVMIO_no_completion. So 
the question is how it is being set and why does this not result in the 
appropriate completion call? I fear this patch is covering up a more 
fundamental problem with the state model in certain cases.

  Paul

> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2107,6 +2107,7 @@ static int _hvm_emulate_one(struct hvm_e
>  hvm_emulate_init_per_insn(hvmemul_ctxt, vio->mmio_insn,
>vio->mmio_insn_bytes);
> 
> +vio->io_completion = HVMIO_no_completion;
>  vio->mmio_retry = 0;
> 
>  rc = x86_emulate(_ctxt->ctxt, ops);
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -139,6 +139,8 @@ bool handle_pio(uint16_t port, unsigned
>  if ( dir == IOREQ_WRITE )
>  data = guest_cpu_user_regs()->eax;
> 
> +vio->io_completion = HVMIO_no_completion;
> +
>  rc = hvmemul_do_pio_buffer(port, size, dir, );
> 
>  if ( hvm_vcpu_io_need_completion(vio) )
> 
> 


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

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Jan Beulich]

>>> On 28.11.17 at 10:12,  wrote:
> In theory the BIOS would search for address space and won't find 
> anything, so the hotplug operation should fail even before it reaches 
> the kernel in the first place.

How would the BIOS know what the OS does or plans to do? I think
it's the other way around - the OS needs to avoid using any regions
for MMIO which are marked as hotpluggable in SRAT. Since there is
no vNUMA yet for Xen Dom0, that would need special handling.

Jan


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

[Xen-devel] [PATCH 3/3] x86/xen: supply rsdp address in boot params for pvh guests

[Juergen Gross]

When booted via the special PVH entry save the RSDP address set in the
boot information block in struct boot_params. This will enable Xen to
locate the RSDP at an arbitrary address.

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/enlighten_pvh.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 436c4f003e17..0175194f4236 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -71,6 +71,8 @@ static void __init init_pvh_bootparams(void)
 */
pvh_bootparams.hdr.version = 0x212;
pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+
+   pvh_bootparams.hdr.acpi_rsdp_addr = pvh_start_info.rsdp_paddr;
 }
 
 /*
-- 
2.12.3


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

[Xen-devel] [PATCH 0/3] x86: make rsdp address accessible via boot params

[Juergen Gross]

In the non-EFI boot path the ACPI RSDP table is currently found via
either EBDA or by searching through low memory for the RSDP magic.
This requires the RSDP to be located in the first 1MB of physical
memory. Xen PVH guests, however, get the RSDP address via the start of
day information block.

In order to support an arbitrary RSDP address this patch series adds
the physical address of the RSDP to the boot params structure filled
by the boot loader. A kernel booted directly in PVH mode can save the
RSDP address in the boot params, while a kernel booted in PVH mode via
grub can rely on the RSDP address being specified by grub2 (which in
turn got the address via the start of day information block from Xen).

Juergen Gross (3):
  x86/boot: add acpi rsdp address to setup_header
  x86/acpi: take rsdp address for boot params if available
  x86/xen: supply rsdp address in boot params for pvh guests

 Documentation/x86/boot.txt| 19 +++
 arch/x86/boot/header.S|  6 +-
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 arch/x86/xen/enlighten_pvh.c  |  2 ++
 drivers/acpi/osl.c|  8 
 5 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.12.3


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

[Xen-devel] [PATCH 1/3] x86/boot: add acpi rsdp address to setup_header

[Juergen Gross]

Xen PVH guests receive the address of the RSDP table from Xen. In order
to support booting a Xen PVH guest via grub2 using the standard x86
boot entry we need a way fro grub2 to pass the RSDP address to the
kernel.

For this purpose expand the struct setup_header to hold the physical
address of the RSDP address. Being zero means it isn't specified and
has to be located the legacy way (searching through low memory or
EBDA).

Signed-off-by: Juergen Gross 
---
 Documentation/x86/boot.txt| 19 +++
 arch/x86/boot/header.S|  6 +-
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 5e9b826b5f62..a33c224797e4 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -61,6 +61,13 @@ Protocol 2.12:   (Kernel 3.8) Added the xloadflags field 
and extension fields
to struct boot_params for loading bzImage and ramdisk
above 4G in 64bit.
 
+Protocol 2.13: (Kernel 3.14) Support 32- and 64-bit flags being set in
+   xloadflags to support booting a 64 bit kernel from 32 bit
+   EFI
+
+Protocol 2.14  (Kernel 4.16) Added acpi_rsdp_addr holding the physical
+   address of the ACPI RSDP table.
+
  MEMORY LAYOUT
 
 The traditional memory map for the kernel loader, used for Image or
@@ -197,6 +204,7 @@ Offset  Proto   NameMeaning
 0258/8 2.10+   pref_addressPreferred loading address
 0260/4 2.10+   init_size   Linear memory required during initialization
 0264/4 2.11+   handover_offset Offset of handover entry point
+0268/8 2.14+   acpi_rsdp_addr  Physical address of RSDP table
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
 real value is 4.
@@ -744,6 +752,17 @@ Offset/size:   0x264/4
 
   See EFI HANDOVER PROTOCOL below for more details.
 
+Field name:acpi_rsdp_addr
+Type:  write
+Offset/size:   0x268/8
+Protocol:  2.14+
+
+  This field can be set by the boot loader to tell the kernel the
+  physical address of the ACPI RSDP table.
+
+  A value of 0 indicates the kernel should fall back to the standard
+  methods to locate the RSDP (search in EBDA/low memory).
+
 
  THE IMAGE CHECKSUM
 
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889..e7184127f309 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -300,7 +300,7 @@ _start:
# Part 2 of the header, from the old setup.S
 
.ascii  "HdrS"  # header signature
-   .word   0x020d  # header version number (>= 0x0105)
+   .word   0x020e  # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
.globl realmode_swtch
 realmode_swtch:.word   0, 0# default_switch, SETUPSEG
@@ -558,6 +558,10 @@ pref_address:  .quad LOAD_PHYSICAL_ADDR
# preferred load addr
 init_size: .long INIT_SIZE # kernel initialization size
 handover_offset:   .long 0 # Filled in by build.c
 
+acpi_rsdp_addr:.quad 0 # 64-bit physical 
pointer to
+   # ACPI RSDP table, added with
+   # version 2.14
+
 # End of setup header #
 
.section ".entrytext", "ax"
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index afdd5ae0fcc4..5742e433e93e 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -85,6 +85,7 @@ struct setup_header {
__u64   pref_address;
__u32   init_size;
__u32   handover_offset;
+   __u64   acpi_rsdp_addr;
 } __attribute__((packed));
 
 struct sys_desc_table {
-- 
2.12.3


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

[Xen-devel] [PATCH 2/3] x86/acpi: take rsdp address for boot params if available

[Juergen Gross]

In case the rsdp address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.

Signed-off-by: Juergen Gross 
---
 drivers/acpi/osl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3bb46cb24a99..3b25e2ad7d75 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -45,6 +45,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86
+#include 
+#endif
+
 #include "internal.h"
 
 #define _COMPONENT ACPI_OS_SERVICES
@@ -195,6 +199,10 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
if (acpi_rsdp)
return acpi_rsdp;
 #endif
+#ifdef CONFIG_X86
+   if (boot_params.hdr.acpi_rsdp_addr)
+   return boot_params.hdr.acpi_rsdp_addr;
+#endif
 
if (efi_enabled(EFI_CONFIG_TABLES)) {
if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
-- 
2.12.3


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

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-libvirt-pair

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-pair
testid xen-boot/src_host

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
  Bug not present: e4880bc5dfb1f02b152e62a894b5c6f3e995b3cf
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/116611/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-libvirt-pair.xen-boot--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-libvirt-pair.xen-boot--src_host
 --summary-out=tmp/116611.bisection-summary --basis-template=115643 
--blessings=real,real-bisect linux-linus test-amd64-amd64-libvirt-pair 
xen-boot/src_host
Searching for failure / basis pass:
 116592 fail [dst_host=pinot0,src_host=pinot1] / 116536 
[dst_host=italia1,src_host=italia0] 116514 [dst_host=fiano0,src_host=fiano1] 
116461 [dst_host=fiano1,src_host=fiano0] 116433 
[dst_host=godello0,src_host=godello1] 116343 
[dst_host=italia0,src_host=italia1] 116316 
[dst_host=godello1,src_host=godello0] 116268 
[dst_host=nobling1,src_host=nobling0] 116226 
[dst_host=elbling0,src_host=elbling1] 116136 [dst_host=pinot1,src_host=pinot0] 
116119 [dst_host=huxelrebe0,src_host=huxelrebe1] 116103 
[dst_host=huxelrebe1,src_host=huxelrebe0] 115718 
[dst_host=italia1,src_host=italia0] 115690 [dst_host=fiano0,src_host=fiano1] 
115678 [dst_host=fiano1,src_host=fiano0] 115643 
[dst_host=godello0,src_host=godello1] 115628 ok.
Failure / basis pass flights: 116592 / 115628
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8ed2b6300ba9e0e49faebb07dc2d7d1cbb38b0b8 
5e9abf87163ad4aeaefef0b02961f8674b0a4879 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
bf87b7f7d91a25404216e0a0f3e628ce9bf1f82e
Basis pass 1bf893406637e852daeaafec6617d3ee3716de25 
5e9abf87163ad4aeaefef0b02961f8674b0a4879 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
e4880bc5dfb1f02b152e62a894b5c6f3e995b3cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
ff93dc55431517ed29c70dbff6721c6b0803acf9
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#1bf893406637e852daeaafec6617d3ee3716de25-8ed2b6300ba9e0e49faebb07dc2d7d1cbb38b0b8
 
git://git.sv.gnu.org/gnulib.git#5e9abf87163ad4aeaefef0b02961f8674b0a4879-5e9abf87163ad4aeaefef0b02961f8674b0a4879
 
https://gitlab.com/keycodemap/keycodemapdb.git#7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0-7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0
 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#e4880bc5dfb1f02b152e62a894b5c6f3e995b3cf-4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#5cd7ce5dde3f228b3b669ed9ca432f588947bd40-b79708a8ed1b3d18bee67baeaf33b3fa529493e2
 
git://xenbits.xen.org/xen.git#ff93dc55431517ed29c70dbff6721c6b0803acf9-bf87b7f7d91a25404216e0a0f3e628ce9bf1f82e
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 3010 nodes in revision graph
Searching for test results:
 115599 [dst_host=baroque0,src_host=baroque1]
 115543 [dst_host=pinot1,src_host=pinot0]
 115573 [dst_host=elbling1,src_host=elbling0]
 115615 [dst_host=chardonnay1,src_host=chardonnay0]
 115628 pass 1bf893406637e852daeaafec6617d3ee3716de25 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116520
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116520
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116520
 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-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  13d45b0dc25ed99a9da0704d01cf21c8fe99f951
baseline version:
 libvirt  8ed2b6300ba9e0e49faebb07dc2d7d1cbb38b0b8

Last test of basis   116520  2017-11-25 04:20:16 Z3 days
Testing same since   116607  2017-11-28 04:25:28 Z0 days1 attempts


People who touched revisions under test:
  Julio Faracco 

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



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

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

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

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/libvirt.git
   8ed2b63..13d45b0  13d45b0dc25ed99a9da0704d01cf21c8fe99f951 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH 9/9] x86/vvmx: Use hvm_copy_{to, from}_guest_virt() to read operands

[Jan Beulich]

>>> On 26.10.17 at 19:03,  wrote:

In the title please use "read/write" or "access".

> @@ -380,17 +383,7 @@ static int operand_read(void *buf, struct vmx_inst_op 
> *op,
>  return X86EMUL_OKAY;
>  }
>  else
> -{
> -pagefault_info_t pfinfo;
> -int rc = hvm_copy_from_guest_linear(buf, op->mem, bytes, 0, );
> -
> -if ( rc == HVMTRANS_bad_linear_to_gfn )
> -hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
> -if ( rc != HVMTRANS_okay )
> -return X86EMUL_EXCEPTION;
> -
> -return X86EMUL_OKAY;
> -}
> +return hvm_copy_from_guest_virt(buf, op->seg, op->offset, bytes, 0);
>  }

Please also drop the now pointless "else".

> @@ -458,9 +451,8 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
>  {
>  struct vcpu *v = current;
>  union vmx_inst_info info;
> -struct segment_register seg;
> -unsigned long base, index, seg_base, disp, offset;
> -int scale, size;
> +unsigned long base, index, disp, offset;
> +int scale;

unsigned int please, if you touch it anyway.

> @@ -496,19 +485,12 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
>  
>  __vmread(EXIT_QUALIFICATION, );
>  
> -size = 1 << (info.fields.addr_size + 1);
> -
> -offset = base + index * scale + disp;
> -base = !mode_64bit || info.fields.segment >= x86_seg_fs ?
> -   seg_base + offset : offset;
> -if ( offset + size - 1 < offset ||
> - (mode_64bit ?
> -  !is_canonical_address((long)base < 0 ? base :
> -base + size - 1) :
> -  offset + size - 1 > seg.limit) )
> -goto gp_fault;
> +decode->op[0].type = VMX_INST_MEMREG_TYPE_MEMORY;
> +decode->op[0].seg = info.fields.segment;
> +decode->op[0].offset = base + index * scale + disp;
> +if ( info.fields.addr_size < 2 )
> +decode->op[0].offset = (uint32_t)decode->op[0].offset;

For 16-bit addressing you need to truncate to 16 bits.

Jan


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

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

[Jan Beulich]

>>> On 27.11.17 at 19:08,  wrote:
> On 27/11/17 17:01, Jan Beulich wrote:
> On 26.10.17 at 19:03,  wrote:
>>> +return X86EMUL_OKAY;
>> This and ...
>>
>>> +}
>>> +else
>>> +{
>>> +pagefault_info_t pfinfo;
>>> +int rc = hvm_copy_from_guest_linear(buf, op->mem, bytes, 0, 
>>> );
>>> +
>>> +if ( rc == HVMTRANS_bad_linear_to_gfn )
>>> +hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
>>> +if ( rc != HVMTRANS_okay )
>>> +return X86EMUL_EXCEPTION;
>>> +
>>> +return X86EMUL_OKAY;
>> ... this should become a uniform ...
>>
>>> +}
>> ... return here.
> 
> I tried this, but later patches in the series need them to move back. 
> Overall, this layout reduces the code churn across the series.

Ah, I see.

Jan


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

Re: [Xen-devel] [PATCH 7/9] x86/vvmx: Use correct sizes when reading operands

[Jan Beulich]

>>> On 26.10.17 at 19:03,  wrote:
> * invvpid has a 128-bit memory operand but we only require the VPID value
>   which lies in the lower 64 bits.

The memory operand (wrongly) isn't being read at all - I don't
understand the above bullet point for that reason.

> @@ -464,6 +462,8 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
>  unsigned long base, index, seg_base, disp, offset;
>  int scale, size;
>  
> +unsigned int bytes = vmx_guest_x86_mode(v);
> +

Except in extraordinary circumstances please don't add blank lines in
the middle of declarations.

Also - don't you get 2 here for 16-bit protected mode, which you'd
need to convert to 4?

> @@ -1801,7 +1803,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
>  gpa = nvcpu->nv_vvmcxaddr;
>  
>  rc = hvm_copy_to_guest_linear(decode.op[0].mem, ,
> -  decode.op[0].len, 0, );
> +  decode.op[0].bytes, 0, );

Just like for vmptrld the operand size is uniformly 64 bits here.

> @@ -1987,9 +1989,9 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
>  {
>  case INVEPT_SINGLE_CONTEXT:
>  {
> -unsigned long eptp;
> +uint64_t eptp;
>  
> -ret = operand_read(, [0], regs, decode.op[0].len);
> +ret = operand_read(, [0], regs, sizeof(eptp));

I think you should read the full 128 bits for correct faulting behavior
(also for invvpid). I also can't derive from the SDM that this reading
won't occur for the INVEPT_ALL_CONTEXT case. Sadly the SDM
doesn't say whether the reserved upper half is enforced to be zero
(which we would then need to emulate), or whether it is being
ignored. For invvpid however it does state that bits 16:63 are being
checked.

Jan


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

Re: [Xen-devel] [PATCH 3/9] x86/vvmx: Extract operand reading logic into operand_read()

[Jan Beulich]

>>> On 26.10.17 at 19:03,  wrote:
> +static int operand_read(void *buf, struct vmx_inst_op *op,
> +struct cpu_user_regs *regs, unsigned int bytes)

const (twice)

> +{
> +if ( op->type == VMX_INST_MEMREG_TYPE_REG )
> +{
> +switch ( bytes )
> +{
> +case 4:
> +*(uint32_t *)buf = reg_read(regs, op->reg_idx);

Looking at patch 7, you leave the upper half of 64-bit variables
uninitialized here as well as in the memory case further down
when passing in a smaller value for "bytes". A decent static
analyzer should flag this, and I think things also wouldn't work
right in a few cases.

Jan


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