[Xen-devel] [xen-4.9-testing test] 136845: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-prev   6 xen-buildfail REGR. vs. 132889
 build-amd64-prev  6 xen-buildfail REGR. vs. 132889
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 136493 REGR. vs. 
132889

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-stop fail in 136493 pass in 136845
 test-amd64-i386-freebsd10-i386 17 guest-localmigrate/x10 fail in 136640 pass 
in 136845
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 136640 
pass in 136845
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
136493
 test-armhf-armhf-xl   7 xen-boot   fail pass in 136640
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
136640
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
136640

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 132889
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail blocked in 132889
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 136640 blocked in 
132889
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 136640 blocked 
in 132889
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 136640 like 132889
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   fail in 136640 like 132889
 test-armhf-armhf-xl 13 migrate-support-check fail in 136640 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 136640 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 132889
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132889
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 132889
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 

[Xen-devel] [linux-next test] 136834: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 136594
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
136594

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 build-armhf-pvops 6 kernel-build fail  like 136594
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 136594
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 136594
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 136594
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136594
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 136594
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 136594
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 136594
 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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 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-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-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxcdb8bac2f78c2c1539418346088c34a17b6f4b25
baseline version:
 linuxa188339ca5a396acc588e5851ed7e19f66b0ebd9

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   136834  2019-05-23 03:00:30 Z1 days1 attempts

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  88e798210b459a720253034bffcd76aff15bbbd2
baseline version:
 xen  6fdde9e30846d09dfe0bf0f68de4afa13ef10c22

Last test of basis   136906  2019-05-24 17:00:43 Z0 days
Testing same since   136914  2019-05-24 20:00:32 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 xenbits.xen.org:/home/xen/git/xen.git
   6fdde9e308..88e798210b  88e798210b459a720253034bffcd76aff15bbbd2 -> smoke

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

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

I was hoping we'd get a list of distros + versions together, but have not had 
any input on specific distros

To make this easier, I created 
https://cryptpad.fr/pad/#/2/pad/edit/9MppkbU36LDcWT12uC6Xk3SQ/ 
Trying something else, as some people have trouble with google docs

Regards
Lars

> On 9 May 2019, at 19:28, Lars Kurth  wrote:
> 
> Hi all,
> 
> following a discussion with committers about Guest testing in OSSTEST, it 
> surfaced that we have not updated what distros we test in OSSTEST for a very 
> long time. All agreed that we should regularly review what we test against: 
> maybe at the beginning of a release cycle
> 
> In any case, currently we test against
> 
> x86 HVM guests:
>  debian-9.4.0-{i386,amd64}-CD-1.iso
>  rhel-server-6.1-i386-dvd.iso
>  win10v1703-x86.iso
>  win7-x64.iso
>  ws16-x64.iso
>  FreeBSD-10.1-CUSTOM-{i386,amd64}-20150525.raw.xz
>  Debian HVM {i386,amd64} via debian-installer netinst [1]
> 
> x86 PV guests:
>  Debian PV {i386,amd64} via debian-installer netinst [1]
> 
> ARM guests:
>  Debian PV via debian-installer netinst [1]
> 
> [1] whatever Debian release osstest itself mostly runs
> 
> So I am opening the floor to suggestions.
> 
> With regards to Windows testing we have some restrictions. We have tried 
> several times to buy additional test licenses, but this never went anywhere 
> (some of the VM licenses are not available for our environment, unless you 
> bulk buy, which is very expensive). The only approach that would allow us to 
> test against different windows versions would be to require everyone who may 
> touch OSSTEST which is not doable.
> 
> I can bring this up with the MS open source office, if there are strong 
> feelings about this and try again
> 
> Lars
> 


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

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

> On 9 May 2019, at 19:43, Rich Persaud  wrote:
> 
> On May 9, 2019, at 21:28, Lars Kurth  > wrote:
> 
>> With regards to Windows testing we have some restrictions. We have tried 
>> several times to buy additional test licenses, but this never went anywhere 
>> (some of the VM licenses are not available for our environment, unless you 
>> bulk buy, which is very expensive). The only approach that would allow us to 
>> test against different windows versions would be to require everyone who may 
>> touch OSSTEST which is not doable.
> 
> Are the 90-day test/eval versions of Windows incompatible with OSSTEST?
> 
>   https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise 
> 
>   https://www.microsoft.com/en-us/evalcenter/ 
> 
> 

Actually, that's a possibility. Our use may not be compatible with the T's of 
the eval license though. It wasn't when we checked last time. But that can be 
checked.
Lars

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

Re: [Xen-devel] [PATCH v1] xen/swiotlb: rework early repeat code

[Stefano Stabellini]

On Fri, 24 May 2019, Sergey Dyasli wrote:
> Current repeat code is plain broken for the early=true case. Xen exchanges
> all DMA (<4GB) pages that it can on the first xen_swiotlb_fixup() attempt.
> All further attempts with a halved region will fail immediately because
> all DMA pages already belong to Dom0.
> 
> Introduce contig_pages param for xen_swiotlb_fixup() to track the number
> of pages that were made contiguous in MFN space and use the same bootmem
> region while halving the memory requirements.
> 
> Signed-off-by: Sergey Dyasli 

Just FYI I am touching the same code to fix another unrelated bug, see:

https://marc.info/?l=xen-devel=155856767022893


> ---
> CC: Konrad Rzeszutek Wilk 
> CC: Boris Ostrovsky 
> CC: Juergen Gross 
> CC: Stefano Stabellini 
> CC: Paul Durrant 
> ---
>  drivers/xen/swiotlb-xen.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 5dcb06fe9667..d2aba804d06c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -142,7 +142,8 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
>  static int max_dma_bits = 32;
>  
>  static int
> -xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
> +xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs,
> +   unsigned long *contig_pages)
>  {
>   int i, rc;
>   int dma_bits;
> @@ -156,10 +157,13 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long 
> nslabs)
>   int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
>  
>   do {
> + unsigned int order = get_order(slabs << IO_TLB_SHIFT);
>   rc = xen_create_contiguous_region(
>   p + (i << IO_TLB_SHIFT),
> - get_order(slabs << IO_TLB_SHIFT),
> + order,
>   dma_bits, _handle);
> + if (rc == 0)
> + *contig_pages += 1 << order;
>   } while (rc && dma_bits++ < max_dma_bits);
>   if (rc)
>   return rc;
> @@ -202,7 +206,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err 
> err)
>  }
>  int __ref xen_swiotlb_init(int verbose, bool early)
>  {
> - unsigned long bytes, order;
> + unsigned long bytes, order, contig_pages;
>   int rc = -ENOMEM;
>   enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>   unsigned int repeat = 3;
> @@ -244,13 +248,32 @@ int __ref xen_swiotlb_init(int verbose, bool early)
>   /*
>* And replace that memory with pages under 4GB.
>*/
> + contig_pages = 0;
>   rc = xen_swiotlb_fixup(xen_io_tlb_start,
>  bytes,
> -xen_io_tlb_nslabs);
> +xen_io_tlb_nslabs,
> +_pages);
>   if (rc) {
> - if (early)
> + if (early) {
> + unsigned long orig_bytes = bytes;
> + while (repeat-- > 0) {
> + xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
> +   (xen_io_tlb_nslabs >> 1));
> + pr_info("Lowering to %luMB\n",
> +  (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
> + bytes = xen_set_nslabs(xen_io_tlb_nslabs);
> + order = get_order(xen_io_tlb_nslabs << 
> IO_TLB_SHIFT);
> + xen_io_tlb_end = xen_io_tlb_start + bytes;
> + if (contig_pages >= (1ul << order)) {
> + /* Enough pages were made contiguous */
> + memblock_free(__pa(xen_io_tlb_start + 
> bytes),
> +  PAGE_ALIGN(orig_bytes - 
> bytes));
> + goto fixup_done;
> + }
> + }
>   memblock_free(__pa(xen_io_tlb_start),
> PAGE_ALIGN(bytes));
> + }
>   else {
>   free_pages((unsigned long)xen_io_tlb_start, order);
>   xen_io_tlb_start = NULL;
> @@ -258,6 +281,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
>   m_ret = XEN_SWIOTLB_EFIXUP;
>   goto error;
>   }
> +fixup_done:
>   start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
>   if (early) {
>   if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
> @@ -272,7 +296,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
>  
>   return rc;
>  error:
> - if (repeat--) {
> + if (repeat-- > 0) {
>   xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
>   

Re: [Xen-devel] [PATCH v8 27/50] x86emul: support AVX512{F, ER} reciprocal insns

[Andrew Cooper]

On 24/05/2019 07:43, Jan Beulich wrote:
 On 23.05.19 at 18:15,  wrote:
>> On 15/03/2019 10:55, Jan Beulich wrote:
>>> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>>>
>>> Note that despite the replacement of the SHA insns' table slots there's
>>> no need to special case their decoding: Their insn-specific code already
>>> sets op_bytes (as was required due to simd_other), and TwoOp is of no
>>> relevance for legacy encoded SIMD insns.
>>>
>>> The raising of #UD when EVEX.L'L is 3 for AVX512ER scalar insns is done
>>> to be on the safe side. The SDM does not clarify behavior there, and
>>> it's even more ambiguous here (without AVX512VL in the picture).
>>>
>>> Signed-off-by: Jan Beulich 
>> Acked-by: Andrew Cooper 
> Thanks, also for the others.
>
>> Seeing as I have some ER hardware, is there an easy way to get
>> GCC/binutils to emit a weird L'L field, or will this involve some manual
>> opcode generation to test?
> gcc does not provide any control at all, afaict. binutils allows "weird"
> VEX.L or EVEX.L'L only for insns it believes ignore that field. So yes,
> I'm afraid this will involve using .byte.

Ok.  Given a test program of:

{
printf("Real:\n");
asm volatile ("vrcp14sd %xmm0,%xmm0,%xmm0");

printf("Bytes:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x08, 0x4d, 0xc0");

printf("Bad 0x28:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x28, 0x4d, 0xc0");

printf("Bad 0x48:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x48, 0x4d, 0xc0");

printf("Bad 0x68:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x68, 0x4d, 0xc0");
}

Then the L'L = 3 case (0x68 at the end) does indeed take #UD for both
KNL and KNM.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  6fdde9e30846d09dfe0bf0f68de4afa13ef10c22
baseline version:
 xen  188164069a1cac3f5ef37837bc01c0d6eada2eee

Last test of basis   136891  2019-05-24 09:01:00 Z0 days
Testing same since   136906  2019-05-24 17:00:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 xenbits.xen.org:/home/xen/git/xen.git
   188164069a..6fdde9e308  6fdde9e30846d09dfe0bf0f68de4afa13ef10c22 -> smoke

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

[Xen-devel] [xen-4.7-testing test] 136841: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 133596
 build-i386-prev   6 xen-buildfail REGR. vs. 133596
 build-i386-xsm6 xen-buildfail REGR. vs. 133596
 build-amd64-prev  6 xen-buildfail REGR. vs. 133596
 build-i3866 xen-buildfail REGR. vs. 133596
 build-amd64-xsm   6 xen-buildfail REGR. vs. 133596
 build-arm64   6 xen-buildfail REGR. vs. 133596
 build-arm64-xsm   6 xen-buildfail REGR. vs. 133596
 build-armhf   6 xen-buildfail REGR. vs. 133596

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked 

[Xen-devel] [xen-unstable bisection] complete test-armhf-armhf-xl-vhd

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-vhd
testid debian-di-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  3802ecbaa9eb36cbadce39ab03a4f6d36f29ae5c
  Bug not present: 2520a7f33836616077a2ca3bd96d0b8bdd7f9404
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/136907/


  commit 3802ecbaa9eb36cbadce39ab03a4f6d36f29ae5c
  Author: Olaf Hering 
  Date:   Tue May 14 09:27:41 2019 +0200
  
  libxl: add helper function to set device_model_version
  
  An upcoming change will set the value of device_model_version properly
  also for the non-HVM case.
  
  Move existing code to new function libxl__domain_set_device_model.
  Move also initialization for device_model_stubdomain to that function.
  Make sure libxl__domain_build_info_setdefault is called with
  device_model_version set.
  
  Update libxl__spawn_stub_dm() and initiate_domain_create() to call the
  new function prior libxl__domain_build_info_setdefault() because
  device_mode_version is expected to be initialzed.
  libxl_domain_need_memory() needs no update because it does not have a
  d_config available anyway, and the callers provide a populated b_info.
  
  The upcoming change needs a full libxl_domain_config, and the existing
  libxl__domain_build_info_setdefault has just a libxl_domain_build_info
  to work with.
  
  Signed-off-by: Olaf Hering 
  Reviewed-by: Roger Pau Monné 
  Acked-by: Wei Liu 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-armhf-armhf-xl-vhd.debian-di-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-armhf-armhf-xl-vhd.debian-di-install
 --summary-out=tmp/136907.bisection-summary --basis-template=136156 
--blessings=real,real-bisect xen-unstable test-armhf-armhf-xl-vhd 
debian-di-install
Searching for failure / basis pass:
 136751 fail [host=arndale-metrocentre] / 136273 [host=arndale-westfield] 
136156 [host=cubietruck-gleizes] 136034 [host=cubietruck-picasso] 135931 
[host=cubietruck-braque] 135816 [host=arndale-lakeside] 135680 
[host=arndale-bluewater] 135481 [host=arndale-westfield] 135425 ok.
Failure / basis pass flights: 136751 / 135425
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
4973997f70860c10093ce34294be0c588ddc8cf3
Basis pass e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
de5b678ca4dcdfa83e322491d478d66df56c1986 
dc497635d93f6672f82727ad97a55205177be2aa
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#e64ac26749dc2c0f390caccd04274608ab31c8cf-e64ac26749dc2c0f390caccd04274608ab31c8cf
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-9cca02d8ffc23e9688a971d858e4ffdff5389b11
 git://xenbits.xen.org/xen.git#dc497635d93f6672f82727ad97a55205177be2aa-4973997\
 f70860c10093ce34294be0c588ddc8cf3
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 1002 nodes in revision graph
Searching for test results:
 135425 pass e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
de5b678ca4dcdfa83e322491d478d66df56c1986 
dc497635d93f6672f82727ad97a55205177be2aa
 135481 [host=arndale-westfield]
 135680 [host=arndale-bluewater]
 135816 [host=arndale-lakeside]
 135931 [host=cubietruck-braque]
 136034 [host=cubietruck-picasso]
 136156 [host=cubietruck-gleizes]
 136273 [host=arndale-westfield]
 136440 fail e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
5945b57b055abcab803d23974e95c3657ef597fb
 136592 fail e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
ae0e5f204cb42440e244419e6a92f7fd90eb25bb
 136751 fail e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
4973997f70860c10093ce34294be0c588ddc8cf3
 136852 pass e64ac26749dc2c0f390caccd04274608ab31c8cf 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
133580
 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580

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

version targeted for testing:
 linux54dee406374ce8adb352c48e175176247cb8db7c
baseline version:
 linux736706bee3298208343a76096370e4f6a5c55915

Last test of basis   133580  2019-03-04 19:53:09 Z   80 days
Failing since133605  2019-03-05 20:03:14 Z   79 days   39 attempts
Testing same since   136823  2019-05-22 17:50:41 Z2 days1 attempts


3196 people touched revisions under test,
not listing them all

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

[Xen-devel] [PATCH v3] Introduce runstate area registration with phys address

[Andrii Anisov]

From: Andrii Anisov 

Following discussion [1] it is introduced and implemented a runstate
registration interface which uses guest's phys address instead of a virtual one.
The new hypercall employes the same data structures as a predecessor, but
expects the vcpu_runstate_info structure to not cross a page boundary.
The interface is implemented in a way vcpu_runstate_info structure is mapped to
the hypervisor on the hypercall processing and is directly accessed during its
updates. This runstate area mapping follows vcpu_info structure registration.

Permanent mapping of runstate area would consume vmap area on arm32 what is
limited to 1G. Though it might be OK because it would be possible to increase 
the ARM32 virtual address area by reworking the address space. 

The series is tested for ARM64. Build tested for x86. I'd appreciate if someone
could check it with x86.
The Linux kernel patch is here [2]. Though it is for 4.14. It is not still
convinced the absolute correctness of that patch, yet this should be better
aligned with linux community.

Changes in:

  v3: This version again implements runstate mapping on init approach.
  Patches are squashed and refactored in order to not allow virt and phys
  interfaces function simultaneously but replace one another on init.
  In order to measure performance impact of permanent mapping vs mapping on
  access there written two RFC patches which follow mapping on access
  approach with the little difference: 
   - RFC 1 - using copy_to_guest_phys_flush_dcache() for each access to
 runstate area.
   - RFC 2 - mapping runstate area before all update manipulations and unmap
 after.

  RFC patches were implemented for ARM only, because performance 
measurements
  were done on ARM64 machine.

  There were made performance measurements of approaches (runstate mapped on
  access vs mapped on registration). The test setups are as following:
 
  Thin Dom0 (Linux with intiramfs) with DomD running rich Yocto Linux. In
  DomD 3d benchmark numbers are compared. The benchmark is GlMark2. GLMark2
  is ran with different resolutions in order to emit different irq load, 
  where 320x240 emits high IRQ load, but 1920x1080 emits low irq load.
  Separately tested baking DomD benchmark run with primitive Dom0 CPU burn
  (dd), in order to stimulate VCPU(dX)->VCPU(dY) switches rather than
  VCPU(dX)->idle->VCPU(dX).
  with following results:

mapped mapped mapped
on initon access  on update
   RFC 1  RFC 2
  GLMark2 320x240   2906   2856 (-2%) 2903 (0)
  +Dom0 CPUBurn 2166   2106 (-3%) 2134 (1%)
  GLMark2 800x600   2396   2367 (-1%) 2393 (0%)
  +Dom0 CPUBurn 1958   1911 (-2%) 1942 (-1%)
  GLMark2 1920x1080 939936  (0%)  935  (0%)
  +Dom0 CPUBurn 909901  (-1%) 907  (0%)

  Also it was checked IRQ latency difference using TBM in a setup similar to
  [5]. Please note that the IRQ rate is one in 30 seconds, and only
  VCPU->idle->VCPU use-case is considered. With following results (in ns,
  the timer granularity 120ns):

  mapped on init:
  max=10080 warm_max=8760 min=6600 avg=6699
  mapped on update (RFC1):
  max=10440 warm_max=7560 min=7320 avg=7419
  mapped on access (RFC2)
  max=11520 warm_max=7920 min=7200 avg=7299

  v2: It was reconsidered the new runstate interface implementation. The new 
  interface is made independent of the old one. Do not share runstate_area
  field, and consequently avoid excessive concurrency with the old runstate
  interface usage.
  Introduced locks in order to resolve possible concurrency between runstate
  area registration and usage. 
  Addressed comments from Jan Beulich [3][4] about coding style nits. Though
  some of them become obsolete with refactoring and few are picked into this
  thread for further discussion.

  There were made performance measurements of approaches (runstate mapped on
  access vs mapped on registration). The test setups are as following:
 
  Thin Dom0 (Linux with intiramfs) with DomD running rich Yocto Linux. In
  DomD 3d benchmark numbers are compared. The benchmark is GlMark2. GLMark2
  is ran with different resolutions in order to emit different irq load, 
  where 320x240 emits high IRQ load, but 1920x1080 emits low irq load.
  Separately tested baking DomD benchmark run with primitive Dom0 CPU burn
  (dd), in order to stimulate VCPU(dX)->VCPU(dY) switches rather than
  VCPU(dX)->idle->VCPU(dX).
  with following results:

mapped   mapped
on accesson init
 

[Xen-devel] [PATCH RFC 2] [DO NOT APPLY] introduce VCPUOP_register_runstate_phys_memory_area hypercall

[Andrii Anisov]

From: Andrii Anisov 

An RFC version of the runstate registration with phys address.
Runstate area access is implemented with mapping on each update once for
all accesses.

Signed-off-by: Andrii Anisov 
---
 xen/arch/arm/domain.c |  63 ++---
 xen/common/domain.c   | 101 --
 xen/include/public/vcpu.h |  15 +++
 xen/include/xen/sched.h   |  28 +
 4 files changed, 190 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a9f7ff5..04c4cff 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -274,17 +274,15 @@ static void ctxt_switch_to(struct vcpu *n)
 virt_timer_restore(n);
 }
 
-/* Update per-VCPU guest runstate shared memory area (if registered). */
-static void update_runstate_area(struct vcpu *v)
+static void update_runstate_by_gvaddr(struct vcpu *v)
 {
 void __user *guest_handle = NULL;
 
-if ( guest_handle_is_null(runstate_guest(v)) )
-return;
+ASSERT(!guest_handle_is_null(runstate_guest_virt(v)));
 
 if ( VM_ASSIST(v->domain, runstate_update_flag) )
 {
-guest_handle = >runstate_guest.p->state_entry_time + 1;
+guest_handle = >runstate_guest.virt.p->state_entry_time + 1;
 guest_handle--;
 v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
 __raw_copy_to_guest(guest_handle,
@@ -292,7 +290,7 @@ static void update_runstate_area(struct vcpu *v)
 smp_wmb();
 }
 
-__copy_to_guest(runstate_guest(v), >runstate, 1);
+__copy_to_guest(runstate_guest_virt(v), >runstate, 1);
 
 if ( guest_handle )
 {
@@ -303,6 +301,58 @@ static void update_runstate_area(struct vcpu *v)
 }
 }
 
+extern int map_runstate_area(struct vcpu *v, struct vcpu_runstate_info **area);
+extern void unmap_runstate_area(struct vcpu_runstate_info *area);
+
+static void update_runstate_by_gpaddr(struct vcpu *v)
+{
+struct vcpu_runstate_info *runstate;
+
+if ( map_runstate_area(v, ) )
+return;
+
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+runstate->state_entry_time |= XEN_RUNSTATE_UPDATE;
+smp_wmb();
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+}
+
+memcpy(runstate, >runstate, sizeof(v->runstate));
+
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+smp_wmb();
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+}
+
+unmap_runstate_area(runstate);
+}
+
+/* Update per-VCPU guest runstate shared memory area (if registered). */
+static void update_runstate_area(struct vcpu *v)
+{
+if ( xchg(>runstate_in_use, 1) )
+return;
+
+switch ( v->runstate_guest_type )
+{
+case RUNSTATE_NONE:
+   break;
+
+case RUNSTATE_VADDR:
+   update_runstate_by_gvaddr(v);
+   break;
+
+case RUNSTATE_PADDR:
+   update_runstate_by_gpaddr(v);
+   break;
+}
+
+xchg(>runstate_in_use, 0);
+}
+
 static void schedule_tail(struct vcpu *prev)
 {
 ctxt_switch_from(prev);
@@ -998,6 +1048,7 @@ long do_arm_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) a
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
+case VCPUOP_register_runstate_phys_memory_area:
 return do_vcpu_op(cmd, vcpuid, arg);
 default:
 return -EINVAL;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 32bca8d..f167a68 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -700,6 +700,68 @@ int rcu_lock_live_remote_domain_by_id(domid_t dom, struct 
domain **d)
 return 0;
 }
 
+void unmap_runstate_area(struct vcpu_runstate_info *area)
+{
+mfn_t mfn;
+
+ASSERT(area != NULL);
+
+mfn = _mfn(domain_page_map_to_mfn(area));
+
+unmap_domain_page_global((void *)
+ ((unsigned long)area &
+  PAGE_MASK));
+
+put_page_and_type(mfn_to_page(mfn));
+}
+
+int map_runstate_area(struct vcpu *v, struct vcpu_runstate_info **area)
+{
+unsigned long offset = v->runstate_guest.phys & ~PAGE_MASK;
+gfn_t gfn = gaddr_to_gfn(v->runstate_guest.phys);
+struct domain *d = v->domain;
+void *mapping;
+struct page_info *page;
+size_t size = sizeof(struct vcpu_runstate_info);
+
+if ( offset > (PAGE_SIZE - size) )
+return -EINVAL;
+
+page = get_page_from_gfn(d, gfn_x(gfn), NULL, P2M_ALLOC);
+if ( !page )
+return -EINVAL;
+
+if ( !get_page_type(page, PGT_writable_page) )
+{
+put_page(page);
+return -EINVAL;
+}
+
+mapping = __map_domain_page_global(page);
+
+if ( mapping == NULL )
+{
+put_page_and_type(page);
+return -ENOMEM;
+}
+
+*area = mapping + offset;
+
+return 0;
+}
+
+static void discard_runstate_area(struct vcpu *v)
+{
+v->runstate_guest_type 

[Xen-devel] [PATCH v3] xen: introduce VCPUOP_register_runstate_phys_memory_area hypercall

[Andrii Anisov]

From: Andrii Anisov 

Existing interface to register runstate are with its virtual address
is prone to issues which became more obvious with KPTI enablement in
guests. The nature of those issues is the fact that the guest could
be interrupted by the hypervisor at any time, and there is no guarantee
to have the registered virtual address translated with the currently
available guest's page tables. Before the KPTI such a situation was
possible in case the guest is caught in the middle of PT processing
(e.g. superpage shattering). With the KPTI this happens also when the
guest runs userspace, so has a pretty high probability.
So it was agreed to register runstate with the guest's physical address
so that its mapping is permanent from the hypervisor point of view. [1]

The hypercall employs the same vcpu_register_runstate_memory_area
structure for the interface, but requires a registered area to not
cross a page boundary.

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg00416.html

Signed-off-by: Andrii Anisov 
---
 xen/arch/arm/domain.c|  58 ++---
 xen/arch/x86/domain.c|  99 ---
 xen/arch/x86/x86_64/domain.c |  16 +-
 xen/common/domain.c  | 121 +++
 xen/include/public/vcpu.h|  15 ++
 xen/include/xen/sched.h  |  28 +++---
 6 files changed, 306 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ff330b3..ecedf1c 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -274,17 +274,15 @@ static void ctxt_switch_to(struct vcpu *n)
 virt_timer_restore(n);
 }
 
-/* Update per-VCPU guest runstate shared memory area (if registered). */
-static void update_runstate_area(struct vcpu *v)
+static void update_runstate_by_gvaddr(struct vcpu *v)
 {
 void __user *guest_handle = NULL;
 
-if ( guest_handle_is_null(runstate_guest(v)) )
-return;
+ASSERT(!guest_handle_is_null(runstate_guest_virt(v)));
 
 if ( VM_ASSIST(v->domain, runstate_update_flag) )
 {
-guest_handle = >runstate_guest.p->state_entry_time + 1;
+guest_handle = >runstate_guest.virt.p->state_entry_time + 1;
 guest_handle--;
 v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
 __raw_copy_to_guest(guest_handle,
@@ -292,7 +290,7 @@ static void update_runstate_area(struct vcpu *v)
 smp_wmb();
 }
 
-__copy_to_guest(runstate_guest(v), >runstate, 1);
+__copy_to_guest(runstate_guest_virt(v), >runstate, 1);
 
 if ( guest_handle )
 {
@@ -303,6 +301,53 @@ static void update_runstate_area(struct vcpu *v)
 }
 }
 
+static void update_runstate_by_gpaddr(struct vcpu *v)
+{
+struct vcpu_runstate_info *runstate =
+(struct vcpu_runstate_info *)v->runstate_guest.phys;
+
+ASSERT(runstate != NULL);
+
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+runstate->state_entry_time |= XEN_RUNSTATE_UPDATE;
+smp_wmb();
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+}
+
+memcpy(v->runstate_guest.phys, >runstate, sizeof(v->runstate));
+
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+smp_wmb();
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+}
+}
+
+/* Update per-VCPU guest runstate shared memory area (if registered). */
+static void update_runstate_area(struct vcpu *v)
+{
+if ( xchg(>runstate_in_use, 1) )
+return;
+
+switch ( v->runstate_guest_type )
+{
+case RUNSTATE_NONE:
+break;
+
+case RUNSTATE_VADDR:
+update_runstate_by_gvaddr(v);
+break;
+
+case RUNSTATE_PADDR:
+update_runstate_by_gpaddr(v);
+break;
+}
+
+xchg(>runstate_in_use, 0);
+}
+
 static void schedule_tail(struct vcpu *prev)
 {
 ASSERT(prev != current);
@@ -998,6 +1043,7 @@ long do_arm_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) a
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
+case VCPUOP_register_runstate_phys_memory_area:
 return do_vcpu_op(cmd, vcpuid, arg);
 default:
 return -EINVAL;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ac960dd..fe71776 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1566,22 +1566,21 @@ void paravirt_ctxt_switch_to(struct vcpu *v)
 }
 
 /* Update per-VCPU guest runstate shared memory area (if registered). */
-bool update_runstate_area(struct vcpu *v)
+static bool update_runstate_by_gvaddr(struct vcpu *v)
 {
 bool rc;
 struct guest_memory_policy policy = { .nested_guest_mode = false };
 void __user *guest_handle = NULL;
 
-if ( guest_handle_is_null(runstate_guest(v)) )
-return true;
+ASSERT(!guest_handle_is_null(runstate_guest_virt(v)));
 
 

[Xen-devel] [PATCH RFC 1] [DO NOT APPLY] introduce VCPUOP_register_runstate_phys_memory_area hypercall

[Andrii Anisov]

From: Andrii Anisov 

An RFC version of the runstate registration with phys address.
Runstate area access is implemented with mapping on each access, like
old interface did.

Signed-off-by: Andrii Anisov 
---
 xen/arch/arm/domain.c | 63 ++-
 xen/common/domain.c   | 51 +++---
 xen/include/public/vcpu.h | 15 +++
 xen/include/xen/sched.h   | 28 +++--
 4 files changed, 140 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a9f7ff5..610957a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -274,17 +274,15 @@ static void ctxt_switch_to(struct vcpu *n)
 virt_timer_restore(n);
 }
 
-/* Update per-VCPU guest runstate shared memory area (if registered). */
-static void update_runstate_area(struct vcpu *v)
+static void update_runstate_by_gvaddr(struct vcpu *v)
 {
 void __user *guest_handle = NULL;
 
-if ( guest_handle_is_null(runstate_guest(v)) )
-return;
+ASSERT(!guest_handle_is_null(runstate_guest_virt(v)));
 
 if ( VM_ASSIST(v->domain, runstate_update_flag) )
 {
-guest_handle = >runstate_guest.p->state_entry_time + 1;
+guest_handle = >runstate_guest.virt.p->state_entry_time + 1;
 guest_handle--;
 v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
 __raw_copy_to_guest(guest_handle,
@@ -292,7 +290,7 @@ static void update_runstate_area(struct vcpu *v)
 smp_wmb();
 }
 
-__copy_to_guest(runstate_guest(v), >runstate, 1);
+__copy_to_guest(runstate_guest_virt(v), >runstate, 1);
 
 if ( guest_handle )
 {
@@ -303,6 +301,58 @@ static void update_runstate_area(struct vcpu *v)
 }
 }
 
+extern int map_runstate_area(struct vcpu *v, struct vcpu_runstate_info **area);
+extern void unmap_runstate_area(struct vcpu_runstate_info *area);
+
+static void update_runstate_by_gpaddr(struct vcpu *v)
+{
+struct domain *d = v->domain;
+paddr_t gpaddr = 0;
+
+
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+gpaddr = v->runstate_guest.phys + offsetof(struct vcpu_runstate_info, 
state_entry_time) + sizeof(uint64_t) - 1;
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+copy_to_guest_phys_flush_dcache (d, gpaddr,
+ (void 
*)(>runstate.state_entry_time + 1) - 1, 1);
+smp_wmb();
+}
+
+copy_to_guest_phys_flush_dcache (d, v->runstate_guest.phys, >runstate, 
sizeof(struct vcpu_runstate_info));
+
+if ( gpaddr )
+{
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+smp_wmb();
+copy_to_guest_phys_flush_dcache (d, gpaddr,
+ (void 
*)(>runstate.state_entry_time + 1) - 1, 1);
+}
+}
+
+/* Update per-VCPU guest runstate shared memory area (if registered). */
+static void update_runstate_area(struct vcpu *v)
+{
+if ( xchg(>runstate_in_use, 1) )
+return;
+
+switch ( v->runstate_guest_type )
+{
+case RUNSTATE_NONE:
+   break;
+
+case RUNSTATE_VADDR:
+   update_runstate_by_gvaddr(v);
+   break;
+
+case RUNSTATE_PADDR:
+   update_runstate_by_gpaddr(v);
+   break;
+}
+
+xchg(>runstate_in_use, 0);
+}
+
 static void schedule_tail(struct vcpu *prev)
 {
 ctxt_switch_from(prev);
@@ -998,6 +1048,7 @@ long do_arm_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) a
 {
 case VCPUOP_register_vcpu_info:
 case VCPUOP_register_runstate_memory_area:
+case VCPUOP_register_runstate_phys_memory_area:
 return do_vcpu_op(cmd, vcpuid, arg);
 default:
 return -EINVAL;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 32bca8d..b58d6dd 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -700,6 +700,18 @@ int rcu_lock_live_remote_domain_by_id(domid_t dom, struct 
domain **d)
 return 0;
 }
 
+static void discard_runstate_area(struct vcpu *v)
+{
+v->runstate_guest_type = RUNSTATE_NONE;
+}
+
+static void discard_runstate_area_locked(struct vcpu *v)
+{
+while ( xchg(>runstate_in_use, 1) );
+discard_runstate_area(v);
+xchg(>runstate_in_use, 0);
+}
+
 int domain_kill(struct domain *d)
 {
 int rc = 0;
@@ -738,7 +750,10 @@ int domain_kill(struct domain *d)
 if ( cpupool_move_domain(d, cpupool0) )
 return -ERESTART;
 for_each_vcpu ( d, v )
+{
+discard_runstate_area_locked(v);
 unmap_vcpu_info(v);
+}
 d->is_dying = DOMDYING_dead;
 /* Mem event cleanup has to go here because the rings 
  * have to be put before we call put_domain. */
@@ -1192,7 +1207,7 @@ int domain_soft_reset(struct domain *d)
 
 for_each_vcpu ( d, v )
 {
-set_xen_guest_handle(runstate_guest(v), NULL);
+discard_runstate_area_locked(v);
 unmap_vcpu_info(v);
 }
 
@@ 

Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot

[PGNet Dev]

After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 
successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that 
efibootmgr functions,

xl list
NameID   Mem VCPUs  
State   Time(s)
Domain-0 0  4015 4 
r- 847.6
Xenstore 131 1 
-b   0.0

dmesg | grep -i pvh
[0.181973] Booting paravirtualized kernel on Xen PVH

efibootmgr
BootCurrent: 
Timeout: 1 seconds
BootOrder: ,0002,0003
Boot* xensvr 
HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0002* UEFI OS   
HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0003* UEFI: Built-in EFI Shell  
VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO

From


https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/

I understand that PVH Dom0 *removes* qemu dependency,

"PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems

PVH combines the best of PV and HVM mode to simplify the interface 
between operating systems with Xen Project Support and the Xen Project 
Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests 
are lightweight HVM guests that use hardware virtualization support for memory 
and privileged instructions. PVH does not require QEMU.

Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via 
dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 
million lines of QEMU code from Xen Project’s computing base shrinking the 
attack surface of Xen Project based systems."

Checking, qemu is still resident,

ps ax | grep qemu
1895 ?Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 
0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null 
-serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile 
/var/run/xen/qemu-dom0.pid

Is this still expected?

If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?

If not, is there some additional config required to disable its use here?


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

[Xen-devel] [PATCH v3] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

An example, what file content may look like is embedded below
repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Changes since v1
* Require a colon after repo:, file:, ... keywords
* Replace manual:|auto: with file: as there auto: use-case was invalid
* Added more verbose description of format

Changes since v2
* Changed some formatting
* Removed examples
* Removed references to https

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 TRACKING.FILES | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 TRACKING.FILES

diff --git a/TRACKING.FILES b/TRACKING.FILES
new file mode 100644
index 00..60c47bdefb
--- /dev/null
+++ b/TRACKING.FILES
@@ -0,0 +1,44 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# file: a mapping to track files
+#
+# Note that repo: entries must come *before* file: entries
+#
+# Repository Definitions are of the following format
+# --
+# repo: name-of-source-repo git|svn url-of-source-repo
+#
+# name-of-source-repo
+#   Name of source repository. The name will be used as reference in file:
+#   statements
+#
+# git|svn
+#   Type of source repository
+#
+# url-of-source-repo
+#   URL of source repository
+#
+# Mappings to track files are of the following format
+# ---
+# file: xen-file name-of-original-repo original-file commit-id
+#
+# xen-file
+#   Xen file that needs to be tracked
+#
+# name-of-original-repo
+#   A reference to a source repository defined by *repo* keyword
+#
+# original-file
+#   File in original-repo from which we regularly want to merge changes
+#   into xen-file
+#
+# commit id
+#   Last commit id of original-file that was deemed to be ok
+#   and either imported into the tree or rejected
+
+version: 1
-- 
2.13.0


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

Re: [Xen-devel] [PATCH v2] x86/altp2m: cleanup p2m_altp2m_lazy_copy

[Andrew Cooper]

On 12/04/2019 21:08, Tamas K Lengyel wrote:
> The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view
> when the guest traps out due to no EPT entry being present in the active view.
> Currently the function took several inputs that it didn't use and also
> locked/unlocked gfns when it didn't need to.
>
> Signed-off-by: Tamas K Lengyel 

Reviewed-by: Andrew Cooper 

Sorry - this fell off my radar.  I've got a separate series which
partially overlaps with this.

If George is happy with both, I'll see about taking this and
rebasing/splicing my fixes around it on commit.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  69a8c64f4b875f0e61f59faa605c31573b06a62a
baseline version:
 libvirt  a699b19f6c362f14bbedcb21b22a7299898b0825

Last test of basis   136609  2019-05-20 10:12:28 Z4 days
Testing same since   136828  2019-05-22 21:00:32 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel P. Berrangé 
  Eric Blake 
  Michal Privoznik 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   a699b19f6c..69a8c64f4b  69a8c64f4b875f0e61f59faa605c31573b06a62a -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 6/6] osstest: use a locally built pkg repository for FreeBSD

[Ian Jackson]

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 6/6] osstest: use a locally 
built pkg repository for FreeBSD"):
> On Thu, May 23, 2019 at 12:06:29PM +0100, Ian Jackson wrote:
> > I realise this is a bit late to be saying this, but had you
> > considered making the packages build a different step in the same
> > job ?  That might make a lot of this go away...
> 
> Do you mean to build the packages in build-prep instead of relying on
> having a custom binary repository?

No.  Maybe I am confused.  I thought your usual flight was
  1  install anointed freebsd
  2  build this freebsd
  3+ build this package repo
  4  install this freebsd (from step 2)
  5  rebuild this freebsd (for testing that the build didn't break)
  6  rebuild this package repo (")
  7+ install this package repoo
  8+ build xen

My question is why 2/3 and 5/6 are different jobs.  If you made 2+3 a
single job (with 2 and 3 being separate steps) then there would only
need to be a single anointment.

> IIRC the package building job takes a non-trivial amount of time (2-3h
> IIRC), because it has to build gcc (for SeaBIOS) and python, perl...

You could make the package building job optional if you only want to
do it some of the time.

> > > + # refkey: freebsd  job: build--freebsd
> > > + # refkey: freebsd-packages job: build--freebsd-packages
> > > +anoint="$anoint \"$anointed\" $flight \
> > > +build-$freebsd_arch-$freebsd_name"
> > 
> > Maybe use an array variable for anount, and then you can avoid the
> > shell \" quoting.
> 
> Please bear with me, but can you elaborate on this?

Roughly,

  anoint=()
  
 anoint+=("$anointed" $flight build-..)
  ...
  ./mg-anoint "${anoint[@]}"

Note that the \" \" construct has gone, because there is now no
additional layer of shell dequoting.

> > There seems like a lot of repetition here.  For example, FREEBSD_DIST
> > overrides FreeBSDDist but /$arch is appended in two places.  Maybe
> > ${FREEBSD_DIST- ... something ... } would be better ?
> 
> OK, let me try to remove some of the duplication here.

Thanks.

Another suggestion I mentioned IRL which I wanted to write down was:
maybe have mg-anoint have a reporting mode where it prints something
suitable for shell `eval'.

> > This feels very similar to the code above, although it lacks the
> > special handling for the version.
> 
> Maybe I can see about factoring some of this into a helper, but there
> are slight differences in both if branches that I'm not sure can be
> factored out.

Mmmm.

> Why I don't start by fixing the repetition of:
> freebsd_runvars="$freebsd_runvars \... and we take it from there?

Sure, let's see what you come up with.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
136600

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136600
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 136600
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 136600
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 136600
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-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  0932c20560574696cf87ddd12623e8c423ee821b
baseline version:
 seabios  18d237b4e43ea24795f522c0aab1b4f54100ca80

Last test of basis   136600  2019-05-20 06:04:12 Z4 days
Testing same since   136825  2019-05-22 18:11:04 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Matt DeVillier 

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-xsmfail
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
 test-amd64-i386-xl-qemuu-debianhvm-i386-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-dmrestrict-amd64-dmrestrictpass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
 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
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  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 0932c20560574696cf87ddd12623e8c423ee821b
Author: Gerd Hoffmann 
Date:   Tue Nov 20 08:06:55 2018 +0100

optionrom: disallow int19 redirect for pnp roms.

Check whenever pnp roms attempt to redirect int19, and in case it does
log a message and undo the redirect.

A pnp rom should not need this, we have BEVs and BCVs for that.
Nevertheless there are roms in the wild which are redirecting int19.
At least some BIOS implementations for physical hardware have a config
option in the setup to allow/disallow int19 redirections, so just not
allowing this seems to be the way to deal with this situation.

Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1642135
Signed-off-by: Gerd Hoffmann 
Tested-by: Matt DeVillier 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P

[George Dunlap]

On 5/7/19 4:14 PM, Julien Grall wrote:
> At the moment, Arm is providing a dummy implementation for the M2P
> helpers used in common code. However, they are quite isolated and could
> be used by other architecture in the future. So move all the helpers in
> xen/mm.h.
> 
> Signed-off-by: Julien Grall 

Acked-by: George Dunlap 

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

[Xen-devel] [xen-4.6-testing test] 136833: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 127792
 build-amd64   6 xen-buildfail REGR. vs. 127792
 build-i386-xsm6 xen-buildfail REGR. vs. 127792
 build-i3866 xen-buildfail REGR. vs. 127792
 build-armhf   6 xen-buildfail REGR. vs. 127792

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] [PATCH 13/14] xen/mm: Convert {s, g}et_gpfn_from_mfn() to use typesafe MFN

[George Dunlap]

On 5/7/19 4:14 PM, Julien Grall wrote:
> The first parameter of {s,g}et_gpfn_from_mfn() is an MFN, so it can be
> switched to use the typesafe.
> 
> At the same time, replace gpfn with pfn in the helpers as they all deal
> with PFN and also turn the macros to static inline.
> 
> Note that the return of the getter and the 2nd parameter of the setter
> have not been converted to use typesafe PFN because it was requiring
> more changes than expected.
> 
> Signed-off-by: Julien Grall 

For the mm bits, I'm happy for this to be checked in as-is, or with any
of the changes proposed in this sub-thread:

Acked-by: George Dunlap 

Sorry for taking so long to get to this, and thanks for taking on this
fairly monumental task.

 -George

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

Re: [Xen-devel] [PATCH 13/14] xen/mm: Convert {s, g}et_gpfn_from_mfn() to use typesafe MFN

[George Dunlap]

On 5/10/19 2:21 PM, Jan Beulich wrote:
>> @@ -1099,19 +1100,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
>>  entry_count++;
>>  continue;
>>  }
>> -mfn = l1e_get_pfn(l1e[i1]);
>> -ASSERT(mfn_valid(_mfn(mfn)));
>> -m2pfn = get_gpfn_from_mfn(mfn);
>> +mfn = l1e_get_mfn(l1e[i1]);
>> +ASSERT(mfn_valid(mfn));
>> +m2pfn = get_pfn_from_mfn(mfn);
>>  if ( m2pfn != gfn &&
>>   type != p2m_mmio_direct &&
>>   !p2m_is_grant(type) &&
>>   !p2m_is_shared(type) )
>>  {
>>  pmbad++;
>> -printk("mismatch: gfn %#lx -> mfn %#lx"
>> -   " -> gfn %#lx\n", gfn, mfn, m2pfn);
>> -P2M_PRINTK("mismatch: gfn %#lx -> mfn %#lx"
>> -   " -> gfn %#lx\n", gfn, mfn, m2pfn);
>> +printk("mismatch: gfn %#lx -> mfn %"PRI_mfn" -> 
>> gfn %#lx\n",
>> +   gfn, mfn_x(mfn), m2pfn);
>> +P2M_PRINTK("mismatch: gfn %#lx -> mfn 
>> %"PRI_mfn" -> gfn %#lx\n",
>> +   gfn, mfn_x(mfn), m2pfn);
> 
> George, do we really mean to have printk() and P2M_PRINTK() here?

Looks like this was introduced (by me!) in a589ff6c179; my best guess is
that it was due to a bad rebase merge.

I'll leave it to Julien to decide if he wants to clean this up or leave
it be.

 -George


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

Re: [Xen-devel] [PATCH v2] xen/vm_event: fix rc check for uninitialized ring

[Razvan Cojocaru]

On 5/24/19 6:23 PM, Juergen Gross wrote:
> vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
> since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
> lists on domain creation"), but the callers test for -ENOSYS.
> 
> Correct the callers.
> 
> Signed-off-by: Juergen Gross 
> ---
> V2: add blank line (Jan Beulich)
> replace two further ENOSYS returns with EOPNOTSUPP (Razvan Cojocaru)

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my email address

[George Dunlap]

On 5/24/19 4:24 PM, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH] tests/x86emul: Annotate test blobs as executable code

[Jan Beulich]

>>> On 24.05.19 at 17:15,  wrote:
> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -149,7 +149,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk 
> Makefile
>   (echo 'static const unsigned int __attribute__((section(".test, 
> \"ax\", @progbits #")))' \
> "$${prefix}_$(arch)$${flavor}[] = {"; \
>od -v -t x $*.bin | sed -e 's/^[0-9]* /0x/' -e 's/ /, 0x/g' -e 
> 's/$$/,/'; \
> -  echo "};") >>$@.new; \
> +  echo "}; asm(\".type $${prefix}_$(arch)$${flavor}, 
> STT_FUNC;\");") >>$@.new; \

Hmm, this seems risky to me - I'd expect a decent compiler to mark
them as STT_OBJECT, and a decent assembler to choke on finding
disagreeing .type directives for the same symbol. Current binutils
looks to simply OR together all the values, and then decide in an
adhoc sequence which type to actually emit:

  if ((flags & BSF_THREAD_LOCAL) != 0)
type = STT_TLS;
  else if ((flags & BSF_GNU_INDIRECT_FUNCTION) != 0)
type = STT_GNU_IFUNC;
  else if ((flags & BSF_FUNCTION) != 0)
type = STT_FUNC;
  else if ((flags & BSF_OBJECT) != 0)
type = STT_OBJECT;
  else if ((flags & BSF_RELC) != 0)
type = STT_RELC;
  else if ((flags & BSF_SRELC) != 0)
type = STT_SRELC;
  else
type = STT_NOTYPE;

I don't think that's sane behavior (albeit it guarantees @function to
win over @object), and hence I'd say it can change at any time.

I wanted to suggest forcing the type change via objcopy, but to
my surprise I couldn't find a respective option.

Jan



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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my email address

[Jan Beulich]

>>> On 24.05.19 at 17:24,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 
(if such is needed in the first place)

Jan



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

Re: [Xen-devel] [PATCH] tests/cpu-policy: Skip building on older versions of GCC

[Jan Beulich]

>>> On 24.05.19 at 16:43,  wrote:
> On 24/05/2019 15:19, Jan Beulich wrote:
> On 24.05.19 at 15:29,  wrote:
>>> --- a/tools/tests/cpu-policy/Makefile
>>> +++ b/tools/tests/cpu-policy/Makefile
>>> @@ -1,8 +1,20 @@
>>>  XEN_ROOT = $(CURDIR)/../../..
>>>  include $(XEN_ROOT)/tools/Rules.mk
>>>  
>>> +TARGET-y := test-cpu-policy
>>> +
>>> +# For brevity, these tests make extensive use of designated initialisers, 
>>> but
>>> +# GCCs older than 4.6 can't cope.  Ignore the test in this case.
>> Designated initializers alone are no problem for old gcc. The issue is
>> with ones used for sub-structures/-unions without field name.
>> Perhaps worth slightly extending the comment to this effect?
> 
> " in anonymous unions" ?  I can never remember exactly which bit it
> chokes on, but I think there are two different ones in practice which
> interfere.

" in anonymous unions" is fine with me.

>>> --- a/tools/tests/x86_emulator/Makefile
>>> +++ b/tools/tests/x86_emulator/Makefile
>>> @@ -97,7 +97,7 @@ $(foreach flavor,$(SIMD) $(FMA),$(eval $(call 
>>> simd-check-cc,$(flavor
>>>  TARGET-$(shell echo 'asm("{evex} vzeroall");' | $(CC) -x c -c -o /dev/null 
>>> > - || echo y) :=
>>>  
>>>  ifeq ($(TARGET-y),)
>>> -$(warning Test harness not built, use newer compiler than "$(CC)")
>>> +$(warning Test harness not built, use newer compiler than $(CC) $(shell 
>>> $(CC) -dumpversion) and an "{evex}" capable assembler)
>>>  endif
>> I appreciate the idea of providing mode information, but I'm afraid
>> this is going to be clumsy in the other direction now:
>>
>> "Test harness not built, use newer compiler than gcc-4.8 4.8 and ..."
>>
>> Naming the compiler binary, I thought, allows the user to figure
>> out the version easily enough. Therefore, please consider
>> dropping that part again.
> 
> I'm afraid you have a selection bias here.  Your compiler binaries may
> have a version suffix, but the overwhelming majority of people who are
> going to hit that error and need to figure out what to do will be using
> their system-provided binaries, as per the commit message.

Well, I can only judge by what the distro does that I use; I wasn't
aware they do something non-standard. I've already avoided
mentioning my own compiler naming scheme.

> What about:
> 
>   ... than "$(CC)" (version $(shell $(CC) -dumpversion)) and ...
> 
> which should (in your example) render as:
> 
>   ... than "gcc-4.8" (version 4.8) and ...
> 
> ?

Better, so let's go with this.

Jan



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

[Xen-devel] [PATCH] MAINTAINERS: update my email address

[Wei Liu]

Signed-off-by: Wei Liu 
---
 MAINTAINERS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a1e040258..3c4326de48 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -311,7 +311,7 @@ F:  tools/ocaml/
 
 OVMF UPSTREAM
 M: Anthony PERARD 
-M: Wei Liu 
+M: Wei Liu 
 S: Supported
 T: git https://xenbits.xenproject.org/git-http/ovmf.git
 
@@ -370,7 +370,7 @@ S:  Supported
 F: xen/common/sched*
 
 SEABIOS UPSTREAM
-M: Wei Liu 
+M: Wei Liu 
 S: Supported
 T: git https://xenbits.xenproject.org/git-http/seabios.git
 
@@ -383,7 +383,7 @@ F:  stubdom/
 
 TOOLSTACK
 M: Ian Jackson 
-M: Wei Liu 
+M: Wei Liu 
 S: Supported
 F: autogen.sh
 F: config/*.in
@@ -437,7 +437,7 @@ F:  docs/misc/vtpm-platforms.txt
 X86 ARCHITECTURE
 M: Jan Beulich 
 M: Andrew Cooper 
-R: Wei Liu 
+R: Wei Liu 
 R: Roger Pau Monné 
 S: Supported
 L: xen-devel@lists.xenproject.org
@@ -513,7 +513,7 @@ M:  Julien Grall 
 M: Konrad Rzeszutek Wilk 
 M: Stefano Stabellini 
 M: Tim Deegan 
-M: Wei Liu 
+M: Wei Liu 
 L: xen-devel@lists.xenproject.org
 S: Supported
 F: *
-- 
2.20.1


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

[Xen-devel] [PATCH v2] xen/vm_event: fix rc check for uninitialized ring

[Juergen Gross]

vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
lists on domain creation"), but the callers test for -ENOSYS.

Correct the callers.

Signed-off-by: Juergen Gross 
---
V2: add blank line (Jan Beulich)
replace two further ENOSYS returns with EOPNOTSUPP (Razvan Cojocaru)
---
 xen/arch/x86/mm/p2m.c | 3 ++-
 xen/common/monitor.c  | 2 +-
 xen/common/vm_event.c | 6 +++---
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 57c5eeda91..8fd3c9d996 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1705,7 +1705,8 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
long gfn_l)
 
 /* We're paging. There should be a ring */
 int rc = vm_event_claim_slot(d, d->vm_event_paging);
-if ( rc == -ENOSYS )
+
+if ( rc == -EOPNOTSUPP )
 {
 gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
  "in place\n", d->domain_id, gfn_l);
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index cb5f37fdb2..d5c9ff1cbf 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -98,7 +98,7 @@ int monitor_traps(struct vcpu *v, bool sync, 
vm_event_request_t *req)
 {
 case 0:
 break;
-case -ENOSYS:
+case -EOPNOTSUPP:
 /*
  * If there was no ring to handle the event, then
  * simply continue executing normally.
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 6e68be47bc..6833c21544 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -64,7 +64,7 @@ static int vm_event_enable(
 /* The parameter defaults to zero, and it should be
  * set to something */
 if ( ring_gfn == 0 )
-return -ENOSYS;
+return -EOPNOTSUPP;
 
 vm_event_ring_lock_init(*ved);
 vm_event_ring_lock(*ved);
@@ -465,7 +465,7 @@ static int vm_event_grab_slot(struct vm_event_domain *ved, 
int foreign)
 unsigned int avail_req;
 
 if ( !ved->ring_page )
-return -ENOSYS;
+return -EOPNOTSUPP;
 
 vm_event_ring_lock(ved);
 
@@ -513,7 +513,7 @@ bool vm_event_check_ring(struct vm_event_domain *ved)
  * this function will always return 0 for a guest.  For a non-guest, we check
  * for space and return -EBUSY if the ring is not available.
  *
- * Return codes: -ENOSYS: the ring is not yet configured
+ * Return codes: -EOPNOTSUPP: the ring is not yet configured
  *   -EBUSY: the ring is busy
  *   0: a spot has been reserved
  *
-- 
2.16.4


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

Re: [Xen-devel] [PATCH 07/14] xen: Convert is_xen_fixed_mfn to use typesafe MFN

[George Dunlap]

On 5/7/19 4:14 PM, Julien Grall wrote:
> No functional changes.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Jan Beulich 
> Acked-by: Stefano Stabellini 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 08/14] xen: Convert is_xen_heap_mfn to use typesafe MFN

[George Dunlap]

On 5/7/19 4:14 PM, Julien Grall wrote:
> No functional changes.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Jan Beulich 
> Acked-by: Stefano Stabellini 

Reviewed-by: George Dunlap 

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

[Xen-devel] [PATCH] tests/x86emul: Annotate test blobs as executable code

[Andrew Cooper]

This causes objdump to disassemble them, rather than rendering them as
straight hex data.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 tools/tests/x86_emulator/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/tests/x86_emulator/Makefile 
b/tools/tests/x86_emulator/Makefile
index 970ec3e..b54603d 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -149,7 +149,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk Makefile
(echo 'static const unsigned int __attribute__((section(".test, 
\"ax\", @progbits #")))' \
  "$${prefix}_$(arch)$${flavor}[] = {"; \
 od -v -t x $*.bin | sed -e 's/^[0-9]* /0x/' -e 's/ /, 0x/g' -e 
's/$$/,/'; \
-echo "};") >>$@.new; \
+echo "}; asm(\".type $${prefix}_$(arch)$${flavor}, 
STT_FUNC;\");") >>$@.new; \
rm -f $*.bin; \
done; \
)
@@ -165,7 +165,7 @@ $(addsuffix -opmask.h,$(OPMASK)): %.h: opmask.S testcase.mk 
Makefile
(echo 'static const unsigned int __attribute__((section(".test, 
\"ax\", @progbits #")))' \
  "$${prefix}_$(arch)$${flavor}[] = {"; \
 od -v -t x $*.bin | sed -e 's/^[0-9]* /0x/' -e 's/ /, 0x/g' -e 
's/$$/,/'; \
-echo "};") >>$@.new; \
+echo "}; asm(\".type $${prefix}_$(arch)$${flavor}, 
STT_FUNC;\");") >>$@.new; \
rm -f $*.bin; \
done; \
)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring

[Juergen Gross]

On 24/05/2019 16:11, Jan Beulich wrote:
 On 24.05.19 at 15:15,  wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d, 
>> unsigned long gfn_l)
>>  
>>  /* We're paging. There should be a ring */
>>  int rc = vm_event_claim_slot(d, d->vm_event_paging);
>> -if ( rc == -ENOSYS )
>> +if ( rc == -EOPNOTSUPP )
> 
> Perhaps while committing (or if a v2 should become necessary)
> the missing blank line could be added here at the same time.

I'll send a V2 with the two missing ENOSYS replacements.


Juergen

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

Re: [Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring

[Juergen Gross]

On 24/05/2019 16:05, Razvan Cojocaru wrote:
> On 5/24/19 4:15 PM, Juergen Gross wrote:
>> vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
>> since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
>> lists on domain creation"), but the callers test for -ENOSYS.
>>
>> Correct the callers.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>   xen/arch/x86/mm/p2m.c | 2 +-
>>   xen/common/monitor.c  | 2 +-
>>   xen/common/vm_event.c | 2 +-
>>   3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 57c5eeda91..8a9a1153a8 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d,
>> unsigned long gfn_l)
>>     /* We're paging. There should be a ring */
>>   int rc = vm_event_claim_slot(d, d->vm_event_paging);
>> -    if ( rc == -ENOSYS )
>> +    if ( rc == -EOPNOTSUPP )
>>   {
>>   gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
>>    "in place\n", d->domain_id, gfn_l);
>> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
>> index cb5f37fdb2..d5c9ff1cbf 100644
>> --- a/xen/common/monitor.c
>> +++ b/xen/common/monitor.c
>> @@ -98,7 +98,7 @@ int monitor_traps(struct vcpu *v, bool sync,
>> vm_event_request_t *req)
>>   {
>>   case 0:
>>   break;
>> -    case -ENOSYS:
>> +    case -EOPNOTSUPP:
>>   /*
>>    * If there was no ring to handle the event, then
>>    * simply continue executing normally.
>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> index 6e68be47bc..7b4ebced16 100644
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -513,7 +513,7 @@ bool vm_event_check_ring(struct vm_event_domain *ved)
>>    * this function will always return 0 for a guest.  For a non-guest,
>> we check
>>    * for space and return -EBUSY if the ring is not available.
>>    *
>> - * Return codes: -ENOSYS: the ring is not yet configured
>> + * Return codes: -EOPNOTSUPP: the ring is not yet configured
>>    *   -EBUSY: the ring is busy
>>    *   0: a spot has been reserved
>>    *
>>
> 
> But vm_event_grab_slot() (which ends up being what vm_event_wait_slot()
> returns), still returns -ENOSYS:
> 
> 463 static int vm_event_grab_slot(struct vm_event_domain *ved, int foreign)
> 464 {
> 465 unsigned int avail_req;
> 466
> 467 if ( !ved->ring_page )
> 468 return -ENOSYS;
> 
> Although we can't get to that part if vm_event_check_ring() returns
> false, we should probably return -EOPNOTSUPP from there as well. In

Hmm, in case the page is removed while a vcpu is waiting for a slot
to become free ENOSYS should still be possible. There is, however, a
race in vm_event_grab_slot(): ved->ring_page is tested outside the
lock, so it could be zeroed just after the test occurred leading to
a "use after free" when calling vm_event_ring_available().

> fact, I wonder if any of the -ENOSYS returns in vm_event.c should not be
> replaced with return -EOPNOTSUPPs.

I believe the ones for the ring page not existing should be replaced,
while the ones for wrong hypercall sub-commands should either remain
or be replaced by EINVAL.

> Anyway, the change does clearly improve the code even without settling
> the above questions, so:
> 
> Acked-by: Razvan Cojocaru 


Juergen


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

[Xen-devel] [PATCH v1] xen/swiotlb: rework early repeat code

[Sergey Dyasli]

Current repeat code is plain broken for the early=true case. Xen exchanges
all DMA (<4GB) pages that it can on the first xen_swiotlb_fixup() attempt.
All further attempts with a halved region will fail immediately because
all DMA pages already belong to Dom0.

Introduce contig_pages param for xen_swiotlb_fixup() to track the number
of pages that were made contiguous in MFN space and use the same bootmem
region while halving the memory requirements.

Signed-off-by: Sergey Dyasli 
---
CC: Konrad Rzeszutek Wilk 
CC: Boris Ostrovsky 
CC: Juergen Gross 
CC: Stefano Stabellini 
CC: Paul Durrant 
---
 drivers/xen/swiotlb-xen.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 5dcb06fe9667..d2aba804d06c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -142,7 +142,8 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
 static int max_dma_bits = 32;
 
 static int
-xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
+xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs,
+ unsigned long *contig_pages)
 {
int i, rc;
int dma_bits;
@@ -156,10 +157,13 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long 
nslabs)
int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
 
do {
+   unsigned int order = get_order(slabs << IO_TLB_SHIFT);
rc = xen_create_contiguous_region(
p + (i << IO_TLB_SHIFT),
-   get_order(slabs << IO_TLB_SHIFT),
+   order,
dma_bits, _handle);
+   if (rc == 0)
+   *contig_pages += 1 << order;
} while (rc && dma_bits++ < max_dma_bits);
if (rc)
return rc;
@@ -202,7 +206,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err 
err)
 }
 int __ref xen_swiotlb_init(int verbose, bool early)
 {
-   unsigned long bytes, order;
+   unsigned long bytes, order, contig_pages;
int rc = -ENOMEM;
enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
unsigned int repeat = 3;
@@ -244,13 +248,32 @@ int __ref xen_swiotlb_init(int verbose, bool early)
/*
 * And replace that memory with pages under 4GB.
 */
+   contig_pages = 0;
rc = xen_swiotlb_fixup(xen_io_tlb_start,
   bytes,
-  xen_io_tlb_nslabs);
+  xen_io_tlb_nslabs,
+  _pages);
if (rc) {
-   if (early)
+   if (early) {
+   unsigned long orig_bytes = bytes;
+   while (repeat-- > 0) {
+   xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
+ (xen_io_tlb_nslabs >> 1));
+   pr_info("Lowering to %luMB\n",
+(xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
+   bytes = xen_set_nslabs(xen_io_tlb_nslabs);
+   order = get_order(xen_io_tlb_nslabs << 
IO_TLB_SHIFT);
+   xen_io_tlb_end = xen_io_tlb_start + bytes;
+   if (contig_pages >= (1ul << order)) {
+   /* Enough pages were made contiguous */
+   memblock_free(__pa(xen_io_tlb_start + 
bytes),
+PAGE_ALIGN(orig_bytes - 
bytes));
+   goto fixup_done;
+   }
+   }
memblock_free(__pa(xen_io_tlb_start),
  PAGE_ALIGN(bytes));
+   }
else {
free_pages((unsigned long)xen_io_tlb_start, order);
xen_io_tlb_start = NULL;
@@ -258,6 +281,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
m_ret = XEN_SWIOTLB_EFIXUP;
goto error;
}
+fixup_done:
start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
if (early) {
if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
@@ -272,7 +296,7 @@ int __ref xen_swiotlb_init(int verbose, bool early)
 
return rc;
 error:
-   if (repeat--) {
+   if (repeat-- > 0) {
xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
(xen_io_tlb_nslabs >> 1));
pr_info("Lowering to %luMB\n",
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH] tests/cpu-policy: Skip building on older versions of GCC

[Andrew Cooper]

On 24/05/2019 15:19, Jan Beulich wrote:
 On 24.05.19 at 15:29,  wrote:
>> GCC 4.4 (as included in CentOS 6) is too old to handle designated 
>> initialisers
>> in anonymous unions.  As this is just a developer tool, skip the test in this
>> case, rather than sacraficing the legibility/expresibility of the test cases.
>>
>> This fixes the Gitlab CI tests.
>>
>> While adding this logic to cpu-polcy, adjust the equivelent logic from
>> x86_emulator on which this was based.  Printing:
>>
>>   Test harness not built, use newer compiler than "gcc"
>>
>> isn't helpful for anyone unexpectedly encountering the error.
>>
>> Signed-off-by: Andrew Cooper 
> Fundamentally
> Reviewed-by: Jan Beulich 
> But there are remarks:
>
>> --- a/tools/tests/cpu-policy/Makefile
>> +++ b/tools/tests/cpu-policy/Makefile
>> @@ -1,8 +1,20 @@
>>  XEN_ROOT = $(CURDIR)/../../..
>>  include $(XEN_ROOT)/tools/Rules.mk
>>  
>> +TARGET-y := test-cpu-policy
>> +
>> +# For brevity, these tests make extensive use of designated initialisers, 
>> but
>> +# GCCs older than 4.6 can't cope.  Ignore the test in this case.
> Designated initializers alone are no problem for old gcc. The issue is
> with ones used for sub-structures/-unions without field name.
> Perhaps worth slightly extending the comment to this effect?

" in anonymous unions" ?  I can never remember exactly which bit it
chokes on, but I think there are two different ones in practice which
interfere.

>
>> --- a/tools/tests/x86_emulator/Makefile
>> +++ b/tools/tests/x86_emulator/Makefile
>> @@ -97,7 +97,7 @@ $(foreach flavor,$(SIMD) $(FMA),$(eval $(call 
>> simd-check-cc,$(flavor
>>  TARGET-$(shell echo 'asm("{evex} vzeroall");' | $(CC) -x c -c -o /dev/null 
>> - || echo y) :=
>>  
>>  ifeq ($(TARGET-y),)
>> -$(warning Test harness not built, use newer compiler than "$(CC)")
>> +$(warning Test harness not built, use newer compiler than $(CC) $(shell 
>> $(CC) -dumpversion) and an "{evex}" capable assembler)
>>  endif
> I appreciate the idea of providing mode information, but I'm afraid
> this is going to be clumsy in the other direction now:
>
> "Test harness not built, use newer compiler than gcc-4.8 4.8 and ..."
>
> Naming the compiler binary, I thought, allows the user to figure
> out the version easily enough. Therefore, please consider
> dropping that part again.

I'm afraid you have a selection bias here.  Your compiler binaries may
have a version suffix, but the overwhelming majority of people who are
going to hit that error and need to figure out what to do will be using
their system-provided binaries, as per the commit message.

What about:

  ... than "$(CC)" (version $(shell $(CC) -dumpversion)) and ...

which should (in your example) render as:

  ... than "gcc-4.8" (version 4.8) and ...

?

~Andrew

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

Re: [Xen-devel] [PATCH] tests/cpu-policy: Skip building on older versions of GCC

[Jan Beulich]

>>> On 24.05.19 at 15:29,  wrote:
> GCC 4.4 (as included in CentOS 6) is too old to handle designated initialisers
> in anonymous unions.  As this is just a developer tool, skip the test in this
> case, rather than sacraficing the legibility/expresibility of the test cases.
> 
> This fixes the Gitlab CI tests.
> 
> While adding this logic to cpu-polcy, adjust the equivelent logic from
> x86_emulator on which this was based.  Printing:
> 
>   Test harness not built, use newer compiler than "gcc"
> 
> isn't helpful for anyone unexpectedly encountering the error.
> 
> Signed-off-by: Andrew Cooper 

Fundamentally
Reviewed-by: Jan Beulich 
But there are remarks:

> --- a/tools/tests/cpu-policy/Makefile
> +++ b/tools/tests/cpu-policy/Makefile
> @@ -1,8 +1,20 @@
>  XEN_ROOT = $(CURDIR)/../../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
> +TARGET-y := test-cpu-policy
> +
> +# For brevity, these tests make extensive use of designated initialisers, but
> +# GCCs older than 4.6 can't cope.  Ignore the test in this case.

Designated initializers alone are no problem for old gcc. The issue is
with ones used for sub-structures/-unions without field name.
Perhaps worth slightly extending the comment to this effect?

> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -97,7 +97,7 @@ $(foreach flavor,$(SIMD) $(FMA),$(eval $(call 
> simd-check-cc,$(flavor
>  TARGET-$(shell echo 'asm("{evex} vzeroall");' | $(CC) -x c -c -o /dev/null 
> - || echo y) :=
>  
>  ifeq ($(TARGET-y),)
> -$(warning Test harness not built, use newer compiler than "$(CC)")
> +$(warning Test harness not built, use newer compiler than $(CC) $(shell 
> $(CC) -dumpversion) and an "{evex}" capable assembler)
>  endif

I appreciate the idea of providing mode information, but I'm afraid
this is going to be clumsy in the other direction now:

"Test harness not built, use newer compiler than gcc-4.8 4.8 and ..."

Naming the compiler binary, I thought, allows the user to figure
out the version easily enough. Therefore, please consider
dropping that part again.

I'm unconditionally fine with the {evex} addition.

Jan



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

Re: [Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring

[Jan Beulich]

>>> On 24.05.19 at 15:15,  wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
> long gfn_l)
>  
>  /* We're paging. There should be a ring */
>  int rc = vm_event_claim_slot(d, d->vm_event_paging);
> -if ( rc == -ENOSYS )
> +if ( rc == -EOPNOTSUPP )

Perhaps while committing (or if a v2 should become necessary)
the missing blank line could be added here at the same time.

Jan



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

Re: [Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring

[Razvan Cojocaru]

On 5/24/19 4:15 PM, Juergen Gross wrote:

vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
lists on domain creation"), but the callers test for -ENOSYS.

Correct the callers.

Signed-off-by: Juergen Gross 
---
  xen/arch/x86/mm/p2m.c | 2 +-
  xen/common/monitor.c  | 2 +-
  xen/common/vm_event.c | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 57c5eeda91..8a9a1153a8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
long gfn_l)
  
  /* We're paging. There should be a ring */

  int rc = vm_event_claim_slot(d, d->vm_event_paging);
-if ( rc == -ENOSYS )
+if ( rc == -EOPNOTSUPP )
  {
  gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
   "in place\n", d->domain_id, gfn_l);
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index cb5f37fdb2..d5c9ff1cbf 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -98,7 +98,7 @@ int monitor_traps(struct vcpu *v, bool sync, 
vm_event_request_t *req)
  {
  case 0:
  break;
-case -ENOSYS:
+case -EOPNOTSUPP:
  /*
   * If there was no ring to handle the event, then
   * simply continue executing normally.
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 6e68be47bc..7b4ebced16 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -513,7 +513,7 @@ bool vm_event_check_ring(struct vm_event_domain *ved)
   * this function will always return 0 for a guest.  For a non-guest, we check
   * for space and return -EBUSY if the ring is not available.
   *
- * Return codes: -ENOSYS: the ring is not yet configured
+ * Return codes: -EOPNOTSUPP: the ring is not yet configured
   *   -EBUSY: the ring is busy
   *   0: a spot has been reserved
   *



But vm_event_grab_slot() (which ends up being what vm_event_wait_slot() 
returns), still returns -ENOSYS:


463 static int vm_event_grab_slot(struct vm_event_domain *ved, int foreign)
464 {
465 unsigned int avail_req;
466
467 if ( !ved->ring_page )
468 return -ENOSYS;

Although we can't get to that part if vm_event_check_ring() returns 
false, we should probably return -EOPNOTSUPP from there as well. In 
fact, I wonder if any of the -ENOSYS returns in vm_event.c should not be 
replaced with return -EOPNOTSUPPs.


Anyway, the change does clearly improve the code even without settling 
the above questions, so:


Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 5/5] tools/libxc: allow controlling the max C-state sub-state

[Wei Liu]

On Thu, May 23, 2019 at 06:19:39AM -0600, Jan Beulich wrote:
> From: Ross Lagerwall 
> 
> Signed-off-by: Ross Lagerwall 
> 
> Make handling in do_pm_op() more homogeneous: Before interpreting
> op->cpuid as such, handle all operations not acting on a particular
> CPU. Also expose the setting via xenpm.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] tests/cpu-policy: Skip building on older versions of GCC

[Wei Liu]

On Fri, May 24, 2019 at 02:29:46PM +0100, Andrew Cooper wrote:
> GCC 4.4 (as included in CentOS 6) is too old to handle designated initialisers
> in anonymous unions.  As this is just a developer tool, skip the test in this
> case, rather than sacraficing the legibility/expresibility of the test cases.
> 
> This fixes the Gitlab CI tests.
> 
> While adding this logic to cpu-polcy, adjust the equivelent logic from
> x86_emulator on which this was based.  Printing:
> 
>   Test harness not built, use newer compiler than "gcc"
> 
> isn't helpful for anyone unexpectedly encountering the error.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

[Xen-devel] [PATCH] tests/cpu-policy: Skip building on older versions of GCC

[Andrew Cooper]

GCC 4.4 (as included in CentOS 6) is too old to handle designated initialisers
in anonymous unions.  As this is just a developer tool, skip the test in this
case, rather than sacraficing the legibility/expresibility of the test cases.

This fixes the Gitlab CI tests.

While adding this logic to cpu-polcy, adjust the equivelent logic from
x86_emulator on which this was based.  Printing:

  Test harness not built, use newer compiler than "gcc"

isn't helpful for anyone unexpectedly encountering the error.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Ian Jackson 
---
 tools/tests/cpu-policy/Makefile   | 14 +-
 tools/tests/x86_emulator/Makefile |  2 +-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/tests/cpu-policy/Makefile b/tools/tests/cpu-policy/Makefile
index eeed7f3..4b6caec 100644
--- a/tools/tests/cpu-policy/Makefile
+++ b/tools/tests/cpu-policy/Makefile
@@ -1,8 +1,20 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+TARGET-y := test-cpu-policy
+
+# For brevity, these tests make extensive use of designated initialisers, but
+# GCCs older than 4.6 can't cope.  Ignore the test in this case.
+ifneq ($(clang),y)
+TARGET-$(call cc-ver,$(CC),lt,0x040600) :=
+endif
+
+ifeq ($(TARGET-y),)
+$(warning Test harness not built, use newer compiler than $(CC) $(shell $(CC) 
-dumpversion))
+endif
+
 .PHONY: all
-all: test-cpu-policy
+all: $(TARGET-y)
 
 .PHONY: clean
 clean:
diff --git a/tools/tests/x86_emulator/Makefile 
b/tools/tests/x86_emulator/Makefile
index 4f4c0f6..970ec3e 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -97,7 +97,7 @@ $(foreach flavor,$(SIMD) $(FMA),$(eval $(call 
simd-check-cc,$(flavor
 TARGET-$(shell echo 'asm("{evex} vzeroall");' | $(CC) -x c -c -o /dev/null - 
|| echo y) :=
 
 ifeq ($(TARGET-y),)
-$(warning Test harness not built, use newer compiler than "$(CC)")
+$(warning Test harness not built, use newer compiler than $(CC) $(shell $(CC) 
-dumpversion) and an "{evex}" capable assembler)
 endif
 
 all: $(TARGET-y)
-- 
2.1.4


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

[Xen-devel] [freebsd-master test] 136827: regressions - FAIL

[osstest service owner]

flight 136827 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136827/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xen-freebsd   7 xen-build-freebsdfail REGR. vs. 136606
 build-amd64-freebsd-again 7 freebsd-buildfail REGR. vs. 136606

version targeted for testing:
 freebsd  d4527f36d52a6b83a203b54ce67bb9d441bd1c96
baseline version:
 freebsd  cb9788efd6dd2c8377e001d8a85c722ba926f6cf

Last test of basis   136606  2019-05-20 09:25:22 Z4 days
Testing same since   136827  2019-05-22 19:52:30 Z1 days1 attempts


People who touched revisions under test:
  adrian 
  allanjude 
  asomers 
  avg 
  bz 
  cem 
  dchagin 
  dougm 
  emaste 
  gallatin 
  ian 
  jhibbits 
  kib 
  luporl 
  lwhsu 
  manu 
  markj 
  mav 
  mckusick 
  mm 
  ngie 
  sobomax 
  stevek 
  trasz 
  zeising 

jobs:
 build-amd64-freebsd-againfail
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  fail



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.

(No revision log; it would be 1167 lines long.)

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

[Xen-devel] [linux-4.19 test] 136767: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
129313

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

version targeted for testing:
 linuxc3a0725977484ea2d7f17746d7e168d2b19f99a2
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  203 days
Failing since129412  2018-11-04 14:10:15 Z  200 days  123 attempts
Testing same since   136767  2019-05-22 16:41:47 Z1 days1 attempts


2007 people touched revisions under test,
not listing them all

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

[Xen-devel] [PATCH] xen/vm_event: fix rc check for uninitialized ring

[Juergen Gross]

vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
since commit 15e4dd5e866b43bbc ("common/vm_event: Initialize vm_event
lists on domain creation"), but the callers test for -ENOSYS.

Correct the callers.

Signed-off-by: Juergen Gross 
---
 xen/arch/x86/mm/p2m.c | 2 +-
 xen/common/monitor.c  | 2 +-
 xen/common/vm_event.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 57c5eeda91..8a9a1153a8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1705,7 +1705,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
long gfn_l)
 
 /* We're paging. There should be a ring */
 int rc = vm_event_claim_slot(d, d->vm_event_paging);
-if ( rc == -ENOSYS )
+if ( rc == -EOPNOTSUPP )
 {
 gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
  "in place\n", d->domain_id, gfn_l);
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index cb5f37fdb2..d5c9ff1cbf 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -98,7 +98,7 @@ int monitor_traps(struct vcpu *v, bool sync, 
vm_event_request_t *req)
 {
 case 0:
 break;
-case -ENOSYS:
+case -EOPNOTSUPP:
 /*
  * If there was no ring to handle the event, then
  * simply continue executing normally.
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 6e68be47bc..7b4ebced16 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -513,7 +513,7 @@ bool vm_event_check_ring(struct vm_event_domain *ved)
  * this function will always return 0 for a guest.  For a non-guest, we check
  * for space and return -EBUSY if the ring is not available.
  *
- * Return codes: -ENOSYS: the ring is not yet configured
+ * Return codes: -EOPNOTSUPP: the ring is not yet configured
  *   -EBUSY: the ring is busy
  *   0: a spot has been reserved
  *
-- 
2.16.4


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

Re: [Xen-devel] [PATCH] x86/CPUID: adjust SSEn dependencies

[Andrew Cooper]

On 24/05/2019 13:36, Jan Beulich wrote:
> Along the lines of b9f6395590 ("x86/cpuid: adjust dependencies of
> post-SSE ISA extensions") further convert SSEn dependencies to be more
> chain like, with each successor addition depending on its immediate
> predecessor. This is more in line with how hardware has involved, and
> how other projects like gcc and binutils connect things together.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] vsprintf: constify "end" parameters

[Jan Beulich]

Except in the top level function we don't mean to ever write through
"end". The variable is used solely for pointer comparison purposes
there. Add const everywhere.

Also make function heading wrapping style uniform again for all of the
involved functions.

Signed-off-by: Jan Beulich 

--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -144,7 +144,7 @@ static int skip_atoi(const char **s)
 #define LARGE   64  /* use 'ABCDEF' instead of 'abcdef' */
 
 static char *number(
-char *buf, char *end, unsigned long long num,
+char *buf, const char *end, unsigned long long num,
 int base, int size, int precision, int type)
 {
 char c,sign,tmp[66];
@@ -238,7 +238,7 @@ static char *number(
 return buf;
 }
 
-static char *string(char *str, char *end, const char *s,
+static char *string(char *str, const char *end, const char *s,
 int field_width, int precision, int flags)
 {
 int i, len = (precision < 0) ? strlen(s) : strnlen(s, precision);
@@ -265,8 +265,9 @@ static char *string(char *str, char *end
 }
 
 /* Print a bitmap as '0-3,6-15' */
-static char *print_bitmap_list(
-char *str, char *end, const unsigned long *bitmap, unsigned int nr_bits)
+static char *print_bitmap_list(char *str, const char *end,
+   const unsigned long *bitmap,
+   unsigned int nr_bits)
 {
 /* current bit is 'cur', most recently seen range is [rbot, rtop] */
 unsigned int cur, rbot, rtop;
@@ -306,8 +307,9 @@ static char *print_bitmap_list(
 }
 
 /* Print a bitmap as a comma separated hex string. */
-static char *print_bitmap_string(
-char *str, char *end, const unsigned long *bitmap, unsigned int nr_bits)
+static char *print_bitmap_string(char *str, const char *end,
+ const unsigned long *bitmap,
+ unsigned int nr_bits)
 {
 const unsigned int CHUNKSZ = 32;
 unsigned int chunksz;
@@ -347,7 +349,7 @@ static char *print_bitmap_string(
 }
 
 /* Print a domain id, using names for system domains.  (e.g. d0 or d[IDLE]) */
-static char *print_domain(char *str, char *end, const struct domain *d)
+static char *print_domain(char *str, const char *end, const struct domain *d)
 {
 const char *name = NULL;
 
@@ -378,7 +380,7 @@ static char *print_domain(char *str, cha
 }
 
 /* Print a vcpu id.  (e.g. d0v1 or d[IDLE]v0) */
-static char *print_vcpu(char *str, char *end, const struct vcpu *v)
+static char *print_vcpu(char *str, const char *end, const struct vcpu *v)
 {
 /* Some debugging may have an optionally-NULL pointer. */
 if ( unlikely(!v) )
@@ -392,7 +394,7 @@ static char *print_vcpu(char *str, char
 return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
 }
 
-static char *pointer(char *str, char *end, const char **fmt_ptr,
+static char *pointer(char *str, const char *end, const char **fmt_ptr,
  const void *arg, int field_width, int precision,
  int flags)
 {





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

[Xen-devel] [PATCH] x86/CPUID: adjust SSEn dependencies

[Jan Beulich]

Along the lines of b9f6395590 ("x86/cpuid: adjust dependencies of
post-SSE ISA extensions") further convert SSEn dependencies to be more
chain like, with each successor addition depending on its immediate
predecessor. This is more in line with how hardware has involved, and
how other projects like gcc and binutils connect things together.

Signed-off-by: Jan Beulich 

--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -196,18 +196,16 @@ def crunch_numbers(state):
 # instructions.  Several futher instruction sets are built on core
 # %XMM support, without specific inter-dependencies.  Additionally
 # AMD has a special mis-alignment sub-mode.
-SSE: [SSE2, SSE3, SSSE3, SSE4A, MISALIGNSSE],
+SSE: [SSE2, MISALIGNSSE],
 
 # SSE2 was re-specified as core instructions for 64bit.  Also ISA
 # extensions dealing with vectors of integers are added here rather
 # than to SSE.
-SSE2: [LM, AESNI, PCLMULQDQ, SHA],
+SSE2: [SSE3, LM, AESNI, PCLMULQDQ, SHA],
 
-# SSE4.1 explicitly depends on SSE3 and SSSE3
-SSE3: [SSE4_1],
-SSSE3: [SSE4_1],
-
-# SSE4.2 explicitly depends on SSE4.1
+# Other SSEn each depend on their predecessor versions.
+SSE3: [SSSE3],
+SSSE3: [SSE4_1, SSE4A],
 SSE4_1: [SSE4_2],
 
 # AMD specify no relationship between POPCNT and SSE4.2.  Intel





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

Re: [Xen-devel] [PATCH 1/3] xen: drop in_atomic()

[Jan Beulich]

>>> On 24.05.19 at 14:30,  wrote:
> On 24/05/2019 09:39, Jan Beulich wrote:
> On 24.05.19 at 10:34,  wrote:
>>> On 24/05/2019 08:38, Jan Beulich wrote:
>>> On 24.05.19 at 07:41,  wrote:
> On 22/05/2019 12:10, Jan Beulich wrote:
> On 22.05.19 at 11:45,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>>  
>>>  ASSERT(is_hvm_vcpu(v));
>>>  
>>> -/*
>>> - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
>>> - * such as query_size. Grant-table code currently does 
> copy_to/from_guest
>>> - * accesses under the big per-domain lock, which this test would 
> disallow.
>>> - * The test is not needed until we implement sleeping-on-waitqueue 
>>> when
>>> - * we access a paged-out frame, and that's post 4.1.0 now.
>>> - */
>>> -#if 0
>>> -/*
>>> - * If the required guest memory is paged out, this function may 
>>> sleep.
>>> - * Hence we bail immediately if called from atomic context.
>>> - */
>>> -if ( in_atomic() )
>>> -return HVMTRANS_unhandleable;
>>> -#endif
>> Dealing with this TODO item is of course much appreciated, but
>> should it really be deleted altogether? The big-domain-lock issue
>> is gone afair, in which case dropping the #if 0 would seem
>> possible to me, even if it's not strictly needed without the sleep-
>> on-waitqueue behavior mentioned.
> I just had a look and found the following path:
>
> do_domctl() (takes domctl_lock and hypercall_deadlock_mutex)
>   arch_do_domctl()
> raw_copy_from_guest()
>   copy_from_user_hvm()
> hvm_copy_from_guest_linear()
>   __hvm_copy()
>
> So no, we can't do the in_atomic() test IMO.
 Oh, right - that's a PVH constraint that could probably not even
 be thought of that the time the comment was written. I'm still
 of the opinion though that at least the still applicable part of
 the comment should be kept in place. Whether this means also
 keeping in_atomic() itself is then an independent question, i.e.
 I wouldn't consider it overly bad if there was no implementation
 in the tree, but the above still served as documentation of what
 would need to be re-added. Still my preference would be for it
 to be kept.
>>> Would you be okay with replacing the removed stuff above with:
>>>
>>> /*
>>>  * If the required guest memory is paged out this function may sleep.
>>>  * So in theory we should bail out if called in atomic context.
>>>  * Unfortunately this is true for PVH dom0 doing domctl calls which
>> ... this is true at least for ...
>>
>>>  * holds the domctl lock when accessing dom0 memory. OTOH dom0 memory
>>>  * should never be paged out, so we are fine without testing for
>>>  * atomic context.
>>>  */
>> Not sure about this Dom0-specific remark: Are we certain there are
>> no other paths, similar to the gnttab one having been mentioned till
>> now?
> 
> Why is __hvm_copy() so special?  It is just one of many places which can
> end up touching guest memory.

Are you sure? I think everything that can touch guest (HVM) memory
actually ends up calling into this function.

Jan



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

Re: [Xen-devel] [PATCH 1/3] xen: drop in_atomic()

[Andrew Cooper]

On 24/05/2019 09:39, Jan Beulich wrote:
 On 24.05.19 at 10:34,  wrote:
>> On 24/05/2019 08:38, Jan Beulich wrote:
>> On 24.05.19 at 07:41,  wrote:
 On 22/05/2019 12:10, Jan Beulich wrote:
 On 22.05.19 at 11:45,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>  
>>  ASSERT(is_hvm_vcpu(v));
>>  
>> -/*
>> - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
>> - * such as query_size. Grant-table code currently does 
>> copy_to/from_guest
>> - * accesses under the big per-domain lock, which this test would 
>> disallow.
>> - * The test is not needed until we implement sleeping-on-waitqueue 
>> when
>> - * we access a paged-out frame, and that's post 4.1.0 now.
>> - */
>> -#if 0
>> -/*
>> - * If the required guest memory is paged out, this function may 
>> sleep.
>> - * Hence we bail immediately if called from atomic context.
>> - */
>> -if ( in_atomic() )
>> -return HVMTRANS_unhandleable;
>> -#endif
> Dealing with this TODO item is of course much appreciated, but
> should it really be deleted altogether? The big-domain-lock issue
> is gone afair, in which case dropping the #if 0 would seem
> possible to me, even if it's not strictly needed without the sleep-
> on-waitqueue behavior mentioned.
 I just had a look and found the following path:

 do_domctl() (takes domctl_lock and hypercall_deadlock_mutex)
   arch_do_domctl()
 raw_copy_from_guest()
   copy_from_user_hvm()
 hvm_copy_from_guest_linear()
   __hvm_copy()

 So no, we can't do the in_atomic() test IMO.
>>> Oh, right - that's a PVH constraint that could probably not even
>>> be thought of that the time the comment was written. I'm still
>>> of the opinion though that at least the still applicable part of
>>> the comment should be kept in place. Whether this means also
>>> keeping in_atomic() itself is then an independent question, i.e.
>>> I wouldn't consider it overly bad if there was no implementation
>>> in the tree, but the above still served as documentation of what
>>> would need to be re-added. Still my preference would be for it
>>> to be kept.
>> Would you be okay with replacing the removed stuff above with:
>>
>> /*
>>  * If the required guest memory is paged out this function may sleep.
>>  * So in theory we should bail out if called in atomic context.
>>  * Unfortunately this is true for PVH dom0 doing domctl calls which
> ... this is true at least for ...
>
>>  * holds the domctl lock when accessing dom0 memory. OTOH dom0 memory
>>  * should never be paged out, so we are fine without testing for
>>  * atomic context.
>>  */
> Not sure about this Dom0-specific remark: Are we certain there are
> no other paths, similar to the gnttab one having been mentioned till
> now?

Why is __hvm_copy() so special?  It is just one of many places which can
end up touching guest memory.

A comment here isn't going to help anyone who might find themselves with
problems.

Given that the test has never been used, and no issues have been raised,
and this path isn't AFAICT special, I don't see why it should be
special-cased.

~Andrew

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

Re: [Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 24/05/2019, 05:24, "Jan Beulich"  wrote:

>>> On 24.05.19 at 03:36,  wrote:
> --- /dev/null
> +++ b/TRACKING.FILES
> @@ -0,0 +1,50 @@
> +# This file contains information about source files that have been
> +# copied from other sources and need to be tracked
> +#
> +# The file may contain lines starting with ...
> +# 
> +# version: of file format
> +# repo: repository definition
> +# file: a mapping to track files
> +#
> +# Note that repo: entries must come *before* file: entries
> +#
> +# Repository Definitions are of the following format
> +# --
> +# repo: name-of-source-repo git|svn https-url-of-source-repo
> +#
> +# name-of-source-repo:
> +#   Name of source repository. The name will be used as reference in 
file:
> +#   statements

May I suggest another formatting change, as the colon uses now
have different meaning:

# repo:   
#
# 
#   Name of source repository. The name will be used as reference in file:
#   statements

> +# git|svn:
> +#   Type ofsource repository

Nit: Missing blank.

> +# https-url-of-source-repo:
> +#   URL of source repository

Why https? Any form of URL should be fine here.

Sure. I think Ian suggested originally.

> +# For example:
> +#   repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 

Didn't we agree on examples moving into the commit message,
or the post-commit-message area, as they'll become redundant
(and eventually stale) once we gain actual content here?

Ah yes, I had forgotten about this

Lars



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

Re: [Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Jan Beulich]

>>> On 24.05.19 at 03:36,  wrote:
> --- /dev/null
> +++ b/TRACKING.FILES
> @@ -0,0 +1,50 @@
> +# This file contains information about source files that have been
> +# copied from other sources and need to be tracked
> +#
> +# The file may contain lines starting with ...
> +# 
> +# version: of file format
> +# repo: repository definition
> +# file: a mapping to track files
> +#
> +# Note that repo: entries must come *before* file: entries
> +#
> +# Repository Definitions are of the following format
> +# --
> +# repo: name-of-source-repo git|svn https-url-of-source-repo
> +#
> +# name-of-source-repo:
> +#   Name of source repository. The name will be used as reference in file:
> +#   statements

May I suggest another formatting change, as the colon uses now
have different meaning:

# repo:   
#
# 
#   Name of source repository. The name will be used as reference in file:
#   statements

> +# git|svn:
> +#   Type ofsource repository

Nit: Missing blank.

> +# https-url-of-source-repo:
> +#   URL of source repository

Why https? Any form of URL should be fine here.

> +# For example:
> +#   repo: linux-torvalds git 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 

Didn't we agree on examples moving into the commit message,
or the post-commit-message area, as they'll become redundant
(and eventually stale) once we gain actual content here?

Jan



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

Re: [Xen-devel] [PATCH 5/6] osstest: introduce a script to build a FreeBSD package repository

[Ian Jackson]

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 5/6] osstest: introduce a 
script to build a FreeBSD package repository"):
> On Thu, May 23, 2019 at 11:38:57AM +0100, Ian Jackson wrote:
> > I notice that none of your freebsd build jobs pass any share- hostflag
> > so they always use a fresh installation.  Is that necessary ?
> 
> Hm, I don't think so. build-amd64-xen-freebsd and
> build-amd64-freebsd-again could share a host. I need to take a look at
> how to do this, I could send this as a separate fix for the existing
> jobs.

Sure.  It's achieved by putting share-SOMETHING in (any of) the
hostflags runvars.  SOMETHING needs to include the value of every
setting which makes a difference, except the osstest revision (which
is added implictly).  Jobs with identical SOMETHING can share.

> > > +# Consumes the following input runvars:
> > > +# svnrevision_freebsdports: ports svn revision id to use.
> > > +# svntree_freebsdports ports svn tree to fetch the source code from.
> > 
> > More regular in osstest terms would be
> >   tree_freebsdports
> >   revision_freebsdports
> >   treevcs_freebsdports=svn
> > But I guess svn is sufficiently unlike what osstest expects out of a
> > vcs that this is not feasible, and it is better to do it this way.
> 
> I don't really have an opinion, I somehow assumed that using the same
> format might interfere with things like bisection, so I've decided to
> pass the git revision using tree_freebsdports  and the svn revision
> using the newly introduced flags.

Well, svn is awkward to cache and to use and probably we couldn't get
the bisector to work with it, indeed.  So err I guess I'm saying leave
it as it is.

> > > +sub create_jail() {
> > > +my $src_prefix = $r{"freebsd_distpath"} ||
> > > + get_stashed("path_freebsddist", 
> > > $r{"freebsdbuildjob"});
> > > +my $dst_prefix = "/root/sets";
> > 
> > Do we need a jail for this ?  We have a whole baremetal OS install
> > whose entire purpose is to do this build ...
> 
> Yes, that's how the repository package builder (poudriere) works, it
> requires a jail to do the package building. In our case it's not so
> important, but I assume this is mostly done to always use a clean
> install, so that currently installed packages on the system don't
> interfere with package building.

Fair enough.

Ian.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  188164069a1cac3f5ef37837bc01c0d6eada2eee
baseline version:
 xen  679216943f545cad8ab0fa32763dd5b9efc44d5f

Last test of basis   136860  2019-05-23 16:00:42 Z0 days
Testing same since   136891  2019-05-24 09:01:00 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Andrew Cooper 
  Igor Druzhinin 
  Jan Beulich 
  Norbert Manthey 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 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 xenbits.xen.org:/home/xen/git/xen.git
   679216943f..188164069a  188164069a1cac3f5ef37837bc01c0d6eada2eee -> smoke

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

Re: [Xen-devel] [PATCH 4/5] print: introduce a format specifier for pci_sbdf_t

[Jan Beulich]

>>> On 24.05.19 at 12:59,  wrote:
> On 24/05/2019 11:36, Jan Beulich wrote:
> On 10.05.19 at 18:10,  wrote:
>>> The new format specifier is '%pp', and prints a pci_sbdf_t using the
>>> seg:bus:dev.func format. Replace all SBDFs printed using
>>> '%04x:%02x:%02x.%u' to use the new format specifier.
>> So on the positive side Linux doesn't use 'p' yet, so we're only at risk
>> of a future conflict. However, having to pass a 64-bit pointer just
>> to print a 32-bit entity seems rather wasteful to me. Since we can't
>> use entirely new format specifiers, did you consider (ab)using one
>> we rarely use, like %o, suffixed similarly like we do for %p? The
>> extension could be restricted to apply only when neither field width
>> nor precision nor any flags were specified, i.e. only to plain %o (at
>> least initially).
>>
>> We'd then have something along the lines of
>>
>> #define PRI_sbdf "op"
>> #define PRI_SBDF(v) ((v).sbdf)
>>
>> and
>>
>> printk("%" PRI_sbdf ": ...\n", PRI_SBDF(pdev->sbdf), ...);
> 
> Except the answer will be the same as every time you've asked this in
> the past.

I don't recall suggesting any use of %o so far. The one thing I
do recall suggesting (and which turned out bad) was using an
l modifier with %pb.

> No, because -Wformat doesn't tolerate it.

How would -Wformat choke here? %o accepts (unsigned) integers,
doesn't it?

Jan



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

Re: [Xen-devel] [PATCH L1TF MDS GT v1 2/3] common/grant_table: harden bound accesses

[Jan Beulich]

>>> On 24.05.19 at 11:54,  wrote:
> On 5/23/19 16:17, Jan Beulich wrote:
> On 21.05.19 at 09:45,  wrote:
>>> Guests can issue grant table operations and provide guest controlled
>>> data to them. This data is used as index for memory loads after bound
>>> checks have been done. To avoid speculative out-of-bound accesses, we
>>> use the array_index_nospec macro where applicable, or the macro
>>> block_speculation. Note, that the block_speculation is always used in
>> s/always/already/ ?
> They both work, but the 'always' underlines that a caller can rely on
> the fact that this will happen on all execution path of that function.
> Hence, I like to stick to 'always' here.

Well, I'm not a native speaker, but to me "always" doesn't express
what you want to express here. What you mean I'd word "... is used
on all paths of ..."

>>> the calls to shared_entry_header and nr_grant_entries, so that no
>>> additional protection is required once these functions have been
>>> called.

As an aside, your use of "in the calls to" looks also misleading to me,
because the fences sit in the functions, not at the call sites.

>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -988,9 +988,10 @@ map_grant_ref(
>>>  PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
>>>   op->ref, rgt->domain->domain_id);
>>>  
>>> -act = active_entry_acquire(rgt, op->ref);
>>> +/* This call also ensures the above check cannot be passed 
>>> speculatively */
>>>  shah = shared_entry_header(rgt, op->ref);
>>>  status = rgt->gt_version == 1 ? >flags : _entry(rgt, 
>>> op->ref);
>>> +act = active_entry_acquire(rgt, op->ref);
>> I know we've been there before, but what guarantees that the
>> compiler won't reload op->ref from memory for either of the
>> latter two accesses? In fact afaict it always will, due to the
>> memory clobber in alternative().
> The compiler can reload op->ref from memory, that is fine here, as the
> bound check happens above, and the shared_entry call comes with an
> lfence() by now, so that we will not continue executing speculatively
> with op->ref being out-of-bounds, independently of whether it's from
> memory or registers.

I don't buy this argumentation: In particular if the cache line got
flushed for whatever reason, the load may take almost arbitrarily
long, opening up a large speculation window again using the
destination register of the load (whatever - not bounds checked -
value that ends up holding).

>>> @@ -3863,6 +3883,9 @@ static int gnttab_get_status_frame_mfn(struct domain 
>>> *d,
>>>  return -EINVAL;
>>>  }
>>>  
>>> +/* Make sure idx is bounded wrt nr_status_frames */
>>> +block_speculation();
>>> +
>>>  *mfn = _mfn(virt_to_mfn(gt->status[idx]));
>>>  return 0;
>>>  }
>> Why don't you use array_index_nospec() here? And how come
> There is no specific reason. I will swap.
>> speculation into gnttab_grow_table() is fine a few lines above?
> I do not see a reason why it would be bad to enter that function
> speculatively. There are no accesses that would have to be protected by
> extra checks, afaict. Otherwise, that function should be protected by
> its own.

Which in fact happens, but only in patch 3. This may be worth saying
explicitly here.

Jan



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

Re: [Xen-devel] [PATCH 4/5] print: introduce a format specifier for pci_sbdf_t

[Andrew Cooper]

On 24/05/2019 11:36, Jan Beulich wrote:
 On 10.05.19 at 18:10,  wrote:
>> The new format specifier is '%pp', and prints a pci_sbdf_t using the
>> seg:bus:dev.func format. Replace all SBDFs printed using
>> '%04x:%02x:%02x.%u' to use the new format specifier.
> So on the positive side Linux doesn't use 'p' yet, so we're only at risk
> of a future conflict. However, having to pass a 64-bit pointer just
> to print a 32-bit entity seems rather wasteful to me. Since we can't
> use entirely new format specifiers, did you consider (ab)using one
> we rarely use, like %o, suffixed similarly like we do for %p? The
> extension could be restricted to apply only when neither field width
> nor precision nor any flags were specified, i.e. only to plain %o (at
> least initially).
>
> We'd then have something along the lines of
>
> #define PRI_sbdf "op"
> #define PRI_SBDF(v) ((v).sbdf)
>
> and
>
> printk("%" PRI_sbdf ": ...\n", PRI_SBDF(pdev->sbdf), ...);

Except the answer will be the same as every time you've asked this in
the past.

No, because -Wformat doesn't tolerate it.

The *only* flexibility we have to play with is suffixes to %p

~Andrew

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

Re: [Xen-devel] [PATCH 5/5] pci: switch PCI capabilities related functions to use pci_sbdf_t

[Jan Beulich]

>>> On 10.05.19 at 18:10,  wrote:
> --- a/xen/drivers/pci/pci.c
> +++ b/xen/drivers/pci/pci.c
> @@ -8,18 +8,12 @@
>  #include 
>  #include 
>  
> -int pci_find_cap_offset(u16 seg, u8 bus, u8 dev, u8 func, u8 cap)
> +int pci_find_cap_offset(pci_sbdf_t sbdf, unsigned int cap)

The secondary type change here and ...

> @@ -45,15 +39,10 @@ int pci_find_cap_offset(u16 seg, u8 bus, u8 dev, u8 func, 
> u8 cap)
>  return 0;
>  }
>  
> -int pci_find_next_cap(u16 seg, u8 bus, unsigned int devfn, u8 pos, int cap)
> +int pci_find_next_cap(pci_sbdf_t sbdf, unsigned int pos, unsigned int cap)

... the two ones here aren't obviously safe, so should at least be
mentioned in the description. The latter function has no caller at
all, so is fine simply by that face, for the former this could in principle
result in change in behavior due to the compiler no longer truncating
possible out-of-range arguments. All callers look to be fine though.
(I don't view this as a potential issue for the "ext" counterparts, as
there it's only a change from plain int to unsigned int.)

Some of the comments given on earlier patches apply here as well.

Jan



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

Re: [Xen-devel] [PATCH 6/6] osstest: use a locally built pkg repository for FreeBSD

[Roger Pau Monné]

On Thu, May 23, 2019 at 12:06:29PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 6/6] osstest: use a locally built 
> pkg repository for FreeBSD"):
> > This removes the dependency on the official pkg repository, which is
> > dangerous when not testing stable branches, since the ABI of the
> > development branch is not stable, and thus it's easy for packages to
> > get out of sync, or for osstest to test an old FreeBSD version that
> > has an ABI different than the one used to build the official
> > packages.
> 
> I realise this is a bit late to be saying this, but had you
> considered making the packages build a different step in the same
> job ?  That might make a lot of this go away...

Do you mean to build the packages in build-prep instead of relying on
having a custom binary repository?

I could do that, but it's going to take some time. Also doing the
package build in build-prep would require fetching the svn ports
repository for each build-prep instance.

IIRC the package building job takes a non-trivial amount of time (2-3h
IIRC), because it has to build gcc (for SeaBIOS) and python, perl...

> >  IFS=$'\n'
> > +count=0
> >  for anointed in \
> > -`./mg-anoint list-prepared "freebsd build $freebsd_branch *"`; do
> > +`./mg-anoint list-prepared "freebsd* build $freebsd_branch *"`; do
> >  # Retrieve previous successful FreeBSD build for each arch.
> >  freebsd_arch=${anointed##* }
> > -freebsd_envvar="FREEBSD_${freebsd_arch^^}_BUILDJOB"
> > +freebsd_name=${anointed%% *}
> > +freebsd_name=${freebsd_name/-/_}
> > +freebsd_envvar="${freebsd_name^^}_${freebsd_arch^^}_BUILDJOB"
> >  if [ "x${!freebsd_envvar}" = "x" ]; then
> > -flight_job=`./mg-anoint retrieve "$anointed"`
> > -export ${freebsd_envvar}=${flight_job/ /.}
> > +   envvars[$count]="$freebsd_envvar"
> > +   refkeys[$count]="$anointed"
> > +   count=$((count+1))
> 
> You don't need this counter.  You can just say
>envvars=()
>...
>envvars+=("$freebsd_envvar")

Oh, thanks!

> > +fi
> > +done
> > +count=0
> > +for flight_job in `./mg-anoint retrieve ${refkeys[@]}`; do
> > +if [ "$flight_job" != "ERROR" ]; then
> > +   export ${envvars[$count]}=${flight_job/ /.}
> >  fi
> > +count=$((count+1))
> 
> I think you do need count here, if you do this as two loops.  But:
> 
> Why not do this retrieve, and set the env vars, inside the first
> loop ?  I think that would avoid having to accumulate a data structure
> full of information in shell variables at all (and shell is not very
> good at this kind of thing).

Yes, I think I can do it as you suggest.

> > @@ -542,17 +553,23 @@ freebsd-*)
> > [ "x$OSSTEST_BLESSING" == "xreal" ]; then
> >  IFS=$'\n'
> >  for anointed in `./mg-anoint list-prepared \
> > - "freebsd build $freebsd_branch *"`; do
> > + "freebsd* build $freebsd_branch *"`; 
> > do
> >  # Update anointed versions
> >  # NB: failure to update an anointed build for a specific arch
> >  # should not be fatal, and it's not an issue if one of the
> >  # arches gets slightly out of sync with the other ones.
> >  freebsd_arch=${anointed##* }
> > -if ./mg-anoint anoint "$anointed" \
> > -   $flight build-$freebsd_arch-freebsd; then
> > -echo "Anointed artifacts from build-$freebsd_arch-freebsd"
> > -fi
> > +freebsd_name=${anointed%% *}
> > +   # Rely on the fact that the job suffix is the same as the
> > +   # anointment refkey. Ie:
> 
> I don't think you mean "Rely on the fact".  Rather, "by definition,
> from the way the flight is constructed, the intended..." ?
> 
> > +   # refkey: freebsd  job: build--freebsd
> > +   # refkey: freebsd-packages job: build--freebsd-packages
> > +anoint="$anoint \"$anointed\" $flight \
> > +build-$freebsd_arch-$freebsd_name"
> 
> Maybe use an array variable for anount, and then you can avoid the
> shell \" quoting.

Please bear with me, but can you elaborate on this?

> > diff --git a/mfi-common b/mfi-common
> > index 83d3c713..12cde85f 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -156,7 +156,6 @@ set_freebsd_runvars () {
> ...
> > +# Check if the packages are provided externally, or else assume they
> > +# are provided by the same flight as the installer binaries.
> > +local pkgpath=`getconfig "FreeBSDPackages"`
> > +counter=0
> > +IFS=$'\n'
> > +for flightjob in `./mg-anoint retrieve --tolerate-unprepared \
> > +  "freebsd build master $arch" \
> > +  "freebsd-packages build master $arch"`; do
> > +if [ $counter -eq 0 ]; then
> > +# Anointed FreeBSD installer
> 
> I don't much like this code, but I'm having trouble saying what I
> 

Re: [Xen-devel] Compiling Xen error on RedHat8.0

[Anthony PERARD]

On Fri, May 24, 2019 at 05:28:50AM +, Chen, Farrah wrote:
> Hi,

Hi,

> Do you have any advice on building Xen on RedHat8? Thanks a lot!

If you're building a release of Xen, then you could try setting
PYTHON=/usr/bin/python2 everywhere, that is when starting configure and
make, something like:

$ ./configure PYTHON=/usr/bin/python2 ...
$ make PYTHON=/usr/bin/python2 ...

If you are building from the unstable tree, I think we fixed most of
those bugs relating to python2/python3.

Is that help?

About the soft link "python" to "python2", you would need a softlink
"python-config" to "python2-config" as well and the "checking for
PyArg_ParseTuple" is more likely to succeed.

Cheers,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 4/5] print: introduce a format specifier for pci_sbdf_t

[Jan Beulich]

>>> On 10.05.19 at 18:10,  wrote:
> The new format specifier is '%pp', and prints a pci_sbdf_t using the
> seg:bus:dev.func format. Replace all SBDFs printed using
> '%04x:%02x:%02x.%u' to use the new format specifier.

So on the positive side Linux doesn't use 'p' yet, so we're only at risk
of a future conflict. However, having to pass a 64-bit pointer just
to print a 32-bit entity seems rather wasteful to me. Since we can't
use entirely new format specifiers, did you consider (ab)using one
we rarely use, like %o, suffixed similarly like we do for %p? The
extension could be restricted to apply only when neither field width
nor precision nor any flags were specified, i.e. only to plain %o (at
least initially).

We'd then have something along the lines of

#define PRI_sbdf "op"
#define PRI_SBDF(v) ((v).sbdf)

and

printk("%" PRI_sbdf ": ...\n", PRI_SBDF(pdev->sbdf), ...);

> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -392,6 +392,20 @@ static char *print_vcpu(char *str, char *end, const 
> struct vcpu *v)
>  return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
>  }
>  
> +static char *print_pci_addr(char *str, char *end, const pci_sbdf_t *sbdf)
> +{
> +str = number(str, end, sbdf->seg, 16, 4, -1, ZEROPAD);
> +if ( str < end )
> +*str = ':';
> +str = number(str + 1, end, sbdf->bus, 16, 2, -1, ZEROPAD);
> +if ( str < end )
> +*str = ':';
> +str = number(str + 1, end, sbdf->dev, 16, 2, -1, ZEROPAD);
> +if ( str < end )
> +*str = '.';
> +return number(str + 1, end, sbdf->func, 10, -1, -1, 0);

It shouldn't really matter, but may I suggest to use 8 instead of 10
here?

> @@ -519,6 +533,10 @@ static char *pointer(char *str, char *end, const char 
> **fmt_ptr,
>  case 'v': /* dv from a struct vcpu */
>  ++*fmt_ptr;
>  return print_vcpu(str, end, arg);
> +
> +case 'p': /* PCI SBDF. */
> +++*fmt_ptr;
> +return print_pci_addr(str, end, arg);
>  }

Please insert at the alphabetically correct place.

> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -717,9 +717,8 @@ static u16 __init parse_ivhd_device_special(
>  return 0;
>  }
>  
> -AMD_IOMMU_DEBUG("IVHD Special: %04x:%02x:%02x.%u variety %#x handle 
> %#x\n",
> -seg, PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf),
> -special->variety, special->handle);
> +AMD_IOMMU_DEBUG("IVHD Special: %pp variety %#x handle %#x\n",
> +_SBDF2_T(seg, bdf), special->variety, 
> special->handle);

The inefficiency of the%p-based approach is perhaps best seen with an
example like this: The compiler will have to instantiate an unnamed variable
on the stack to hold the value of the compound literal, just to be able to
take its address.

> @@ -900,14 +891,10 @@ int pci_release_devices(struct domain *d)
>  return ret;
>  }
>  while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
> -{
> -bus = pdev->sbdf.bus;
> -devfn = pdev->sbdf.extfunc;
> -if ( deassign_device(d, pdev->sbdf.seg, bus, devfn) )
> -printk("domain %d: deassign device (%04x:%02x:%02x.%u) 
> failed!\n",
> -   d->domain_id, pdev->sbdf.seg, bus,
> -   PCI_SLOT(devfn), PCI_FUNC(devfn));
> -}
> +if ( deassign_device(d, pdev->sbdf.seg, pdev->sbdf.bus,
> + pdev->sbdf.extfunc) )
> +printk("domain %d: deassign device (%pp) failed!\n",
> +   d->domain_id, >sbdf);

Could you switch to %pd here (and elsewhere) at the same time?

Jan



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

Re: [Xen-devel] [PATCH 4/6] osstest: introduce a helper to get the svn revision of a git commit

[Ian Jackson]

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 4/6] osstest: introduce a 
helper to get the svn revision of a git commit"):
> On Thu, May 23, 2019 at 11:03:52AM +0100, Ian Jackson wrote:
> > git notes have some different way of travelling than commits, don't
> > they ?  Where is this git note coming from and how do we know it is
> > the right note, IYSWIM ?
> 
> I'm not an expert on this, but I think notes are always stored in a
> separate branch on the same repo? In the FreeBSD case at least it's
> git/refs/notes.

OK, so what are git's rules for where it fetches notes from ?  Which
notes does it look at ?  (Do you understand why I am asking these
questions?)

> > Aside from that, please break the refactoring (in this case, the
> > breaking out of repo_get_realurl) into a separate NFC patch.
> 
> Sure!

Thanks,
Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 136156
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 136156

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136156
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 136156
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 136156
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 136156
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 136156
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 136156
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 136156
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 136156
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 136156
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 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-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 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  4973997f70860c10093ce34294be0c588ddc8cf3
baseline version:
 xen  e83077a3d11072708a5c38fa09fa9d011914e2a1

Last test of basis   136156  2019-05-13 05:08:01 Z   11 days
Failing since136273  2019-05-15 02:51:04 Z9 days4 attempts
Testing same since   136751  2019-05-22 08:41:04 Z2 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alistair Francis 
  Amit Singh Tomar 
  Andrew Cooper 
  Andrew Cooper 
  Andrii Anisov 
  Anthony PERARD 
  Brian Woods 
  

Re: [Xen-devel] [PATCH 5/6] osstest: introduce a script to build a FreeBSD package repository

[Roger Pau Monné]

On Thu, May 23, 2019 at 11:38:57AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 5/6] osstest: introduce a script 
> to build a FreeBSD package repository"):
> > diff --git a/make-freebsd-flight b/make-freebsd-flight
> > index d3c413b5..fc3d2d83 100755
> > --- a/make-freebsd-flight
> > +++ b/make-freebsd-flight
> > @@ -38,13 +38,15 @@ job_create_build_filter_callback () {
> >  
> >  for arch in "$arches"; do
> >  set_freebsd_runvars
> > -
> >  create_freebsd_build_job build-$arch-freebsd
> >  
> > -# Create an identical job that's going to use the build output from
> > -# the previous one.
> > +# Create a job to build the packages against the new world.
> >  freebsd_runvars="$freebsd_runvars freebsdbuildjob=build-$arch-freebsd \
> >   recipe_testinstall=true"
> > +create_freebsd_pkg_build_job build-$arch-freebsd-packages
> > +
> > +# Create an identical job that's going to use the build output from
> > +# the previous one.
> >  create_freebsd_build_job build-$arch-freebsd-again
> >  
> >  # Create a Xen build job that's going to use the output from the first
> 
> This looks OK.
> 
> > @@ -768,7 +773,9 @@ proc prepare-build-host-freebsd {} {
> >  global jobinfo
> >  if {[recipe-flag testinstall]} { set broken fail } { set broken broken 
> > }
> >  run-ts $broken host-install(*) ts-freebsd-host-install
> > -run-ts . host-build-prep ts-build-prep-freebsd
> > +if {![recipe-flag skipbuildprep]} {
> > +run-ts . host-build-prep ts-build-prep-freebsd
> 
> What's this for ?  Oh, I see.

The job that creates the package repository cannot use build-prep
because the packages are not yet built.

> I notice that none of your freebsd build jobs pass any share- hostflag
> so they always use a fresh installation.  Is that necessary ?

Hm, I don't think so. build-amd64-xen-freebsd and
build-amd64-freebsd-again could share a host. I need to take a look at
how to do this, I could send this as a separate fix for the existing
jobs.

> >  proc need-hosts/coverity {} { return BUILD_LINUX }
> > diff --git a/ts-freebsd-build-packages b/ts-freebsd-build-packages
> > new file mode 100755
> > index ..9202dd9f
> > --- /dev/null
> > +++ b/ts-freebsd-build-packages
> > @@ -0,0 +1,145 @@
> > +#!/usr/bin/perl -w
> > +# This is part of "osstest", an automated testing framework for Xen.
> > +# Copyright (C) 2019 Citrix Inc.
> ...
> > +# Consumes the following input runvars:
> > +# svnrevision_freebsdports: ports svn revision id to use.
> > +# svntree_freebsdports ports svn tree to fetch the source code from.
> 
> More regular in osstest terms would be
>   tree_freebsdports
>   revision_freebsdports
>   treevcs_freebsdports=svn
> But I guess svn is sufficiently unlike what osstest expects out of a
> vcs that this is not feasible, and it is better to do it this way.

I don't really have an opinion, I somehow assumed that using the same
format might interfere with things like bisection, so I've decided to
pass the git revision using tree_freebsdports  and the svn revision
using the newly introduced flags.

> > +sub checkout () {
> > +my $u = URI->new($c{HttpProxy});
> > +my $host = $u->host;
> > +my $port = $u->port;
> > +prepbuilddirs();
> > +
> > +logm("Checkout ports tree from svn");
> > +target_cmd_build($ho, 4000, $builddir, < > +cd $builddir
> > +rm -rf ports
> > +# svn ignores HTTP_PROXY envvar
> > +svnlite checkout --config-option servers:global:http-proxy-host=$host \\
> > + --config-option servers:global:http-proxy-port=$port \\
> > + --trust-server-cert \\
> > + $r{"svntree_freebsdports"} \\
> > + -r $r{"svnrevision_freebsdports"} ports
> 
> Will this work to cache the checkout ?  

I think so? Would https somehow prevent the caching?

> All of this says http but I
> assume it's really https ? 

AFAIK svn uses the http-proxy options for both http and https.

> Typically, https clients expect to do the
> TLS themselves but I think you're using our squid mitm and that's what
> "--trust-server-cert" is doing ?

I can't really remember why I've added this option, but I'm quite
sure  it was failing without it. As you say the proxy is acting as a
mitm, so that's likely why trust-server-cert is required.

> Rather than "--trust-server-cert" which disables TLS's own mitm
> protection it would be rather better to inject the osstest mitm squid
> cert into the testbed, but that may be difficult, and the risk is only
> from internal things between the build (test) box and the proxy.

I can look into this, but at the end of day this is all internal, so
I'm not sure there's a lot of risk here.

> > +sub create_jail() {
> > +my $src_prefix = $r{"freebsd_distpath"} ||
> > + get_stashed("path_freebsddist", 
> > $r{"freebsdbuildjob"});
> > +my $dst_prefix = "/root/sets";
> 
> Do we need a jail for this ?  We have 

Re: [Xen-devel] [PATCH 3/5] pci: switch pci_conf_{read/write} to use pci_sbdf_t

[Jan Beulich]

>>> On 10.05.19 at 18:10,  wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -417,15 +417,21 @@ static void disable_c1_ramping(void)
>   int node, nr_nodes;
>  
>   /* Read the number of nodes from the first Northbridge. */
> - nr_nodes = ((pci_conf_read32(0, 0, 0x18, 0x0, 0x60)>>4)&0x07)+1;
> + nr_nodes = ((pci_conf_read32(PCI_SBDF_T(0, 0, 0x18, 0),
> +  0x60)>>4)&0x07)+1;

Could you please add the missing blanks here as you touch this anyway?

>   for (node = 0; node < nr_nodes; node++) {
> + const pci_sbdf_t sbdf = {
> + .dev = 0x18  + node,
> + .func = 0x3

Just like you do above, dropping the unnecessary 0x from this last line
would be nice. (Same again further down.)

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -124,29 +124,20 @@ static void msix_put_fixmap(struct arch_msix *msix, int 
> idx)
>  
>  static bool memory_decoded(const struct pci_dev *dev)
>  {
> -uint8_t bus, slot, func;
> +pci_sbdf_t sbdf = dev->sbdf;
>  
> -if ( !dev->info.is_virtfn )
> +if ( dev->info.is_virtfn )
>  {
> -bus = dev->sbdf.bus;
> -slot = dev->sbdf.dev;
> -func = dev->sbdf.func;
> -}
> -else
> -{
> -bus = dev->info.physfn.bus;
> -slot = PCI_SLOT(dev->info.physfn.devfn);
> -func = PCI_FUNC(dev->info.physfn.devfn);
> +sbdf.bus = dev->info.physfn.bus;
> +sbdf.extfunc = dev->info.physfn.devfn;
>  }
>  
> -return !!(pci_conf_read16(dev->sbdf.seg, bus, slot, func, PCI_COMMAND) &
> -  PCI_COMMAND_MEMORY);
> +return !!(pci_conf_read16(sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY);

Take the opportunity and also drop the pointless !! (and parentheses)?

> @@ -855,20 +859,22 @@ static void _ns16550_resume(struct serial_port *port)
>  {
>  #ifdef CONFIG_HAS_PCI
>  struct ns16550 *uart = port->uart;
> +const pci_sbdf_t sbdf = {
> +.bus = uart->ps_bdf[0],
> +.dev = uart->ps_bdf[1],
> +.func = uart->ps_bdf[2],
> +};

In cases like this one, is there any particular reason you don't use the
macro you introduce?

>  if ( uart->bar )
>  {

Also it looks like the variable could move into this more narrow scope.

> -   pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],
> -PCI_BASE_ADDRESS_0 + uart->bar_idx*4, uart->bar);
> +   pci_conf_write32(sbdf, PCI_BASE_ADDRESS_0 + uart->bar_idx*4, 
> uart->bar);

Ideally add the missing blanks again (many more below)?

> @@ -356,10 +356,16 @@ static int __init acpi_parse_dev_scope(
>  switch ( acpi_scope->entry_type )
>  {
>  case ACPI_DMAR_SCOPE_TYPE_BRIDGE:
> -sec_bus = pci_conf_read8(seg, bus, path->dev, path->fn,
> - PCI_SECONDARY_BUS);
> -sub_bus = pci_conf_read8(seg, bus, path->dev, path->fn,
> - PCI_SUBORDINATE_BUS);
> +{
> +const pci_sbdf_t sbdf = {
> +.seg = seg,
> +.bus = bus,
> +.dev = path->dev,
> +.func = path->fn,
> +};
> +
> +sec_bus = pci_conf_read8(sbdf, PCI_SECONDARY_BUS);
> +sub_bus = pci_conf_read8(sbdf, PCI_SUBORDINATE_BUS);
>  if ( iommu_verbose )
>  printk(VTDPREFIX
> " bridge: %04x:%02x:%02x.%u start=%x sec=%x sub=%x\n",
> @@ -368,7 +374,7 @@ static int __init acpi_parse_dev_scope(
>  
>  dmar_scope_add_buses(scope, sec_bus, sub_bus);
>  break;
> -
> +}
>  case ACPI_DMAR_SCOPE_TYPE_HPET:

Please don't lose the blank line.

> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -61,6 +61,14 @@ static bool_t __read_mostly is_snb_gfx;
>  static u8 *__read_mostly igd_reg_va;
>  static spinlock_t igd_lock;
>  
> +static const pci_sbdf_t igd_sbdf = {
> +.dev = IGD_DEV,
> +};
> +
> +static const pci_sbdf_t ioh_sbdf = {
> +.dev = IOH_DEV,
> +};

There's only a single use of this, and in an __init function. On one
hand we certainly expect the compiler to not emit to .rodata here
in the first place. But then - can we rely on this? If not, this would
want to become __initconst. So on the whole I think I'd prefer if
you used the initializer macro instead, making IGD_DEV and
IOH_DEV both invocations of that macro. That's then also better
in line with uses of the macro elsewhere in this file.

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -58,6 +58,11 @@ typedef union {
>  };
>  } pci_sbdf_t;
>  
> +#define PCI_SBDF_T(s, b, d, f) \
> +((pci_sbdf_t) { .seg = (s), .bus = (b), .dev = (d), .func = (f) })

I'd prefer if the _T suffix could be omitted. Afaics there's no use of the
existing PCI_SBDF() anywhere in the tree, so this should be fine. For

Re: [Xen-devel] [PATCH 4/6] osstest: introduce a helper to get the svn revision of a git commit

[Roger Pau Monné]

On Thu, May 23, 2019 at 11:03:52AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 4/6] osstest: introduce a helper 
> to get the svn revision of a git commit"):
> > This only works when the svn revision is stored as a git note
> > with the format 'revision='.
> 
> Wow.  This is pretty ugly.

Indeed :(.

> 
> > Such conversion is required in order to bootstrap a FreeBSD system
> > without relying on external package repositories. FreeBSD base system
> > only contains a subversion client (no git client), and thus in order
> > to fetch the ports repository (that contain the external packages
> > build makefiles) svn must be used.
> 
> git notes have some different way of travelling than commits, don't
> they ?  Where is this git note coming from and how do we know it is
> the right note, IYSWIM ?

I'm not an expert on this, but I think notes are always stored in a
separate branch on the same repo? In the FreeBSD case at least it's
git/refs/notes.

> Aside from that, please break the refactoring (in this case, the
> breaking out of repo_get_realurl) into a separate NFC patch.

Sure!

Thanks, Roger.

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

Re: [Xen-devel] [PATCH L1TF MDS GT v1 2/3] common/grant_table: harden bound accesses

[Norbert Manthey]

On 5/23/19 16:17, Jan Beulich wrote:
 On 21.05.19 at 09:45,  wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative out-of-bound accesses, we
>> use the array_index_nospec macro where applicable, or the macro
>> block_speculation. Note, that the block_speculation is always used in
> s/always/already/ ?
They both work, but the 'always' underlines that a caller can rely on
the fact that this will happen on all execution path of that function.
Hence, I like to stick to 'always' here.
>
>> the calls to shared_entry_header and nr_grant_entries, so that no
>> additional protection is required once these functions have been
>> called.
> Isn't this too broad a statement? There's some protection, but not
> for just anything that follows.
You are right, to given protection is that any bound check that could
have been bypassed speculatively is enforced after calling one of the
two functions. I will rephrase the commit message accordingly.
>
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -988,9 +988,10 @@ map_grant_ref(
>>  PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
>>   op->ref, rgt->domain->domain_id);
>>  
>> -act = active_entry_acquire(rgt, op->ref);
>> +/* This call also ensures the above check cannot be passed 
>> speculatively */
>>  shah = shared_entry_header(rgt, op->ref);
>>  status = rgt->gt_version == 1 ? >flags : _entry(rgt, 
>> op->ref);
>> +act = active_entry_acquire(rgt, op->ref);
> I know we've been there before, but what guarantees that the
> compiler won't reload op->ref from memory for either of the
> latter two accesses? In fact afaict it always will, due to the
> memory clobber in alternative().
The compiler can reload op->ref from memory, that is fine here, as the
bound check happens above, and the shared_entry call comes with an
lfence() by now, so that we will not continue executing speculatively
with op->ref being out-of-bounds, independently of whether it's from
memory or registers.
>
>> @@ -3863,6 +3883,9 @@ static int gnttab_get_status_frame_mfn(struct domain 
>> *d,
>>  return -EINVAL;
>>  }
>>  
>> +/* Make sure idx is bounded wrt nr_status_frames */
>> +block_speculation();
>> +
>>  *mfn = _mfn(virt_to_mfn(gt->status[idx]));
>>  return 0;
>>  }
> Why don't you use array_index_nospec() here? And how come
There is no specific reason. I will swap.
> speculation into gnttab_grow_table() is fine a few lines above?
I do not see a reason why it would be bad to enter that function
speculatively. There are no accesses that would have to be protected by
extra checks, afaict. Otherwise, that function should be protected by
its own.
> And what about the similar code in gnttab_get_shared_frame_mfn()?
I will add an array_nospec_index there as well.
>
> Jan
>
>




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

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

Re: [Xen-devel] [PATCH 1/6] osstest: introduce a helper to stash a whole directory

[Roger Pau Monné]

On Thu, May 23, 2019 at 10:48:12AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 1/6] osstest: introduce a helper 
> to stash a whole directory"):
> > Without compressing it.
> 
> You've open-coded a recursive directory copy.  Is rsync available on
> $ho at this point ?  I think maybe it could be ...

D'oh, yes, rsync could be made available on $ho at this point.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 3/5] pci: switch pci_conf_{read/write} to use pci_sbdf_t

[Andrew Cooper]

On 10/05/2019 17:10, Roger Pau Monne wrote:
> pci_dev already uses pci_sbdf_t, so propagate the usage of the type to
> pci_conf functions in order to shorten the calls when made from a
> pci_dev struct.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Suravee Suthikulpanit 
> Cc: Brian Woods 
> Cc: Kevin Tian 
> ---
>  xen/arch/x86/cpu/amd.c |  27 ++--
>  xen/arch/x86/dmi_scan.c|   9 +-
>  xen/arch/x86/mm.c  |   2 +-
>  xen/arch/x86/msi.c | 177 +
>  xen/arch/x86/oprofile/op_model_athlon.c|  12 +-
>  xen/arch/x86/x86_64/mmconf-fam10h.c|  13 +-
>  xen/arch/x86/x86_64/mmconfig-shared.c  |  26 +--
>  xen/arch/x86/x86_64/pci.c  |  32 ++--
>  xen/drivers/acpi/reboot.c  |   8 +-
>  xen/drivers/char/ehci-dbgp.c   |  75 +
>  xen/drivers/char/ns16550.c |  80 +-
>  xen/drivers/passthrough/amd/iommu_detect.c |   3 +-
>  xen/drivers/passthrough/amd/iommu_init.c   |  26 +--
>  xen/drivers/passthrough/ats.h  |   4 +-
>  xen/drivers/passthrough/pci.c  | 106 +---
>  xen/drivers/passthrough/vtd/dmar.c |  18 ++-
>  xen/drivers/passthrough/vtd/quirks.c   |  69 
>  xen/drivers/passthrough/x86/ats.c  |  15 +-
>  xen/drivers/pci/pci.c  |  43 +++--
>  xen/drivers/video/vga.c|  21 +--
>  xen/drivers/vpci/header.c  |  53 ++
>  xen/drivers/vpci/msi.c |   6 +-
>  xen/drivers/vpci/msix.c|  12 +-
>  xen/drivers/vpci/vpci.c|  42 ++---
>  xen/include/xen/pci.h  |  29 ++--
>  25 files changed, 444 insertions(+), 464 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index e19a5ead3e..014d88925c 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -417,15 +417,21 @@ static void disable_c1_ramping(void)
>   int node, nr_nodes;
>  
>   /* Read the number of nodes from the first Northbridge. */
> - nr_nodes = ((pci_conf_read32(0, 0, 0x18, 0x0, 0x60)>>4)&0x07)+1;
> + nr_nodes = ((pci_conf_read32(PCI_SBDF_T(0, 0, 0x18, 0),
> +  0x60)>>4)&0x07)+1;

This looks suspiciously like it wants to use MASK_EXTR()

>   for (node = 0; node < nr_nodes; node++) {
> + const pci_sbdf_t sbdf = {
> + .dev = 0x18  + node,
> + .func = 0x3
> + };

What is wrong with something like:

pci_sbdf_t pci = PCI_SBDF_T(0, 0, 0x18 + node, 3);

IMO, the resulting code would be more logical to read as
pci_conf_read8(pci, ...) (or perhaps dev?).  sbdf it a little awkward.

> +
>   /* PMM7: bus=0, dev=0x18+node, function=0x3, register=0x87. */
> - pmm7 = pci_conf_read8(0, 0, 0x18+node, 0x3, 0x87);
> + pmm7 = pci_conf_read8(sbdf, 0x87);
>   /* Invalid read means we've updated every Northbridge. */
>   if (pmm7 == 0xFF)
>   break;
>   pmm7 &= 0xFC; /* clear pmm7[1:0] */
> - pci_conf_write8(0, 0, 0x18+node, 0x3, 0x87, pmm7);
> + pci_conf_write8(sbdf, 0x87, pmm7);
>   printk ("AMD: Disabling C1 Clock Ramping Node #%x\n", node);
>   }
>  }
> @@ -696,8 +702,13 @@ static void init_amd(struct cpuinfo_x86 *c)
>  
>   if (c->x86 == 0x16 && c->x86_model <= 0xf) {
>   if (c == _cpu_data) {
> - l = pci_conf_read32(0, 0, 0x18, 0x3, 0x58);
> - h = pci_conf_read32(0, 0, 0x18, 0x3, 0x5c);
> + const pci_sbdf_t sbdf = {
> + .dev = 0x18,
> + .func = 0x3,
> + };
> +
> + l = pci_conf_read32(sbdf, 0x58);
> + h = pci_conf_read32(sbdf, 0x5c);
>   if ((l & 0x1f) | (h & 0x1))
>   printk(KERN_WARNING
>  "Applying workaround for erratum 792: 
> %s%s%s\n",
> @@ -706,12 +717,10 @@ static void init_amd(struct cpuinfo_x86 *c)
>  (h & 0x1) ? "clearing D18F3x5C[0]" : "");
>  
>   if (l & 0x1f)
> - pci_conf_write32(0, 0, 0x18, 0x3, 0x58,
> -  l & ~0x1f);
> + pci_conf_write32(sbdf, 0x58, l & ~0x1f);
>  
>   if (h & 0x1)
> - pci_conf_write32(0, 0, 0x18, 0x3, 0x5c,
> -  h & ~0x1);
> + 

Re: [Xen-devel] [PATCH 2/5] pci: use function generation macros for pci_config_{write, read}

[Andrew Cooper]

On 10/05/2019 17:10, Roger Pau Monne wrote:
> This avoids code duplication between the helpers.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné 

-1.  I see this as actively making the code worse, not an improvement.

~Andrew

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

Re: [Xen-devel] [PATCH 2/5] pci: use function generation macros for pci_config_{write, read}

[Jan Beulich]

>>> On 10.05.19 at 18:10,  wrote:
> This avoids code duplication between the helpers.
> 
> No functional change intended.
> 
> Signed-off-by: Roger Pau Monné 

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 1/3] xen: drop in_atomic()

[Jan Beulich]

>>> On 24.05.19 at 10:34,  wrote:
> On 24/05/2019 08:38, Jan Beulich wrote:
> On 24.05.19 at 07:41,  wrote:
>>> On 22/05/2019 12:10, Jan Beulich wrote:
>>> On 22.05.19 at 11:45,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>  
>  ASSERT(is_hvm_vcpu(v));
>  
> -/*
> - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
> - * such as query_size. Grant-table code currently does 
> copy_to/from_guest
> - * accesses under the big per-domain lock, which this test would 
> disallow.
> - * The test is not needed until we implement sleeping-on-waitqueue 
> when
> - * we access a paged-out frame, and that's post 4.1.0 now.
> - */
> -#if 0
> -/*
> - * If the required guest memory is paged out, this function may 
> sleep.
> - * Hence we bail immediately if called from atomic context.
> - */
> -if ( in_atomic() )
> -return HVMTRANS_unhandleable;
> -#endif

 Dealing with this TODO item is of course much appreciated, but
 should it really be deleted altogether? The big-domain-lock issue
 is gone afair, in which case dropping the #if 0 would seem
 possible to me, even if it's not strictly needed without the sleep-
 on-waitqueue behavior mentioned.
>>>
>>> I just had a look and found the following path:
>>>
>>> do_domctl() (takes domctl_lock and hypercall_deadlock_mutex)
>>>   arch_do_domctl()
>>> raw_copy_from_guest()
>>>   copy_from_user_hvm()
>>> hvm_copy_from_guest_linear()
>>>   __hvm_copy()
>>>
>>> So no, we can't do the in_atomic() test IMO.
>> 
>> Oh, right - that's a PVH constraint that could probably not even
>> be thought of that the time the comment was written. I'm still
>> of the opinion though that at least the still applicable part of
>> the comment should be kept in place. Whether this means also
>> keeping in_atomic() itself is then an independent question, i.e.
>> I wouldn't consider it overly bad if there was no implementation
>> in the tree, but the above still served as documentation of what
>> would need to be re-added. Still my preference would be for it
>> to be kept.
> 
> Would you be okay with replacing the removed stuff above with:
> 
> /*
>  * If the required guest memory is paged out this function may sleep.
>  * So in theory we should bail out if called in atomic context.
>  * Unfortunately this is true for PVH dom0 doing domctl calls which

... this is true at least for ...

>  * holds the domctl lock when accessing dom0 memory. OTOH dom0 memory
>  * should never be paged out, so we are fine without testing for
>  * atomic context.
>  */

Not sure about this Dom0-specific remark: Are we certain there are
no other paths, similar to the gnttab one having been mentioned till
now?

Jan



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

Re: [Xen-devel] [PATCH 1/3] xen: drop in_atomic()

[Juergen Gross]

On 24/05/2019 08:38, Jan Beulich wrote:
 On 24.05.19 at 07:41,  wrote:
>> On 22/05/2019 12:10, Jan Beulich wrote:
>> On 22.05.19 at 11:45,  wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
  
  ASSERT(is_hvm_vcpu(v));
  
 -/*
 - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
 - * such as query_size. Grant-table code currently does 
 copy_to/from_guest
 - * accesses under the big per-domain lock, which this test would 
 disallow.
 - * The test is not needed until we implement sleeping-on-waitqueue 
 when
 - * we access a paged-out frame, and that's post 4.1.0 now.
 - */
 -#if 0
 -/*
 - * If the required guest memory is paged out, this function may sleep.
 - * Hence we bail immediately if called from atomic context.
 - */
 -if ( in_atomic() )
 -return HVMTRANS_unhandleable;
 -#endif
>>>
>>> Dealing with this TODO item is of course much appreciated, but
>>> should it really be deleted altogether? The big-domain-lock issue
>>> is gone afair, in which case dropping the #if 0 would seem
>>> possible to me, even if it's not strictly needed without the sleep-
>>> on-waitqueue behavior mentioned.
>>
>> I just had a look and found the following path:
>>
>> do_domctl() (takes domctl_lock and hypercall_deadlock_mutex)
>>   arch_do_domctl()
>> raw_copy_from_guest()
>>   copy_from_user_hvm()
>> hvm_copy_from_guest_linear()
>>   __hvm_copy()
>>
>> So no, we can't do the in_atomic() test IMO.
> 
> Oh, right - that's a PVH constraint that could probably not even
> be thought of that the time the comment was written. I'm still
> of the opinion though that at least the still applicable part of
> the comment should be kept in place. Whether this means also
> keeping in_atomic() itself is then an independent question, i.e.
> I wouldn't consider it overly bad if there was no implementation
> in the tree, but the above still served as documentation of what
> would need to be re-added. Still my preference would be for it
> to be kept.

Would you be okay with replacing the removed stuff above with:

/*
 * If the required guest memory is paged out this function may sleep.
 * So in theory we should bail out if called in atomic context.
 * Unfortunately this is true for PVH dom0 doing domctl calls which
 * holds the domctl lock when accessing dom0 memory. OTOH dom0 memory
 * should never be paged out, so we are fine without testing for
 * atomic context.
 */


Juergen

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

[Xen-devel] [ovmf test] 136761: all pass - PUSHED

[osstest service owner]

flight 136761 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136761/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3604174718e2afc950c3cc64c64ba5165c8692bd
baseline version:
 ovmf 48f43c2c56eeaea63a6b7cb811a21b2a86904d86

Last test of basis   136598  2019-05-20 03:53:39 Z4 days
Testing same since   136761  2019-05-22 14:47:51 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Christian Rodriguez 
  Fan, ZhijuX 
  Feng, Bob C 
  Gao, Zhichao 
  Krzysztof Koch 
  Liming Gao 
  Michael D Kinney 
  Ray Ni 
  Rodriguez, Christian 
  Zhichao Gao 
  Zhiju.Fan 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   48f43c2c56..3604174718  3604174718e2afc950c3cc64c64ba5165c8692bd -> 
xen-tested-master

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

Re: [Xen-devel] Compiling Xen error on RedHat8.0

[M A Young]

On Fri, 24 May 2019, Chen, Farrah wrote:

> Hi,
> 
> I met some python related issues when building Xen on RedHat8.0.
> On RedHat8.0, the default python version is python3, and I found Xen has some 
> python2 codes, so I tried to build xen using python2.
> On RedHat8.0, no "python", just "python2" and "python3":
> 
> ls /usr/bin/python*
> /usr/bin/python2/usr/bin/python2.7-config  /usr/bin/python3
> /usr/bin/python3.6-config  /usr/bin/python3.6m-config 
> /usr/bin/python3-config
> /usr/bin/python2.7  /usr/bin/python2-config/usr/bin/python3.6  
> /usr/bin/python3.6m/usr/bin/python3.6m-x86_64-config
> 
> So I created a soft link "python" to "python2":
> 
> ll /usr/bin/python
> lrwxrwxrwx 1 root root 16 May 24 13:08 /usr/bin/python -> /usr/bin/python2
> 
> Then I tried to build xen:
> 
> cd xen
> ./configure --enable-ovmf
> .
> checking for unistd.h... yes
> checking for python-config... no
> checking Python.h usability... yes
> checking Python.h presence... yes
> checking for Python.h... yes
> checking for PyArg_ParseTuple... no
> configure: error: Unable to find a suitable python development library
> configure: error: ./configure failed for tools
> 
> If I use python3(create a soft link "python" to "python3" ), it reported 
> syntax error.
> 
> checking for unistd.h... yes
> checking for python-config... no
>   File "", line 1
> import distutils.sysconfig; print "-I" + 
> distutils.sysconfig.get_config_var("INCLUDEPY")
>  ^
> SyntaxError: invalid syntax
> checking Python.h usability... no
> checking Python.h presence... no
> checking for Python.h... no
> configure: error: Unable to find Python development headers
> configure: error: ./configure failed for tools
> 
> To resolve "Unable to find a suitable python development library", I 
> installed python2-devel*, python2-lib*, python3-devel*, python3-lib*, 
> python2-six, python3-six, but this error still exists.
> In RedHat7, these packages are called "python-devel*, python-lib*", but in 
> RedHat8, these packages don't exists, RedHat8 has only "python2-devel*, 
> python2-lib*, python3-devel*, python3-lib*", maybe Xen codes cannot identify 
> them.
> 
> Do you have any advice on building Xen on RedHat8? Thanks a lot!

If you want to go down the python3 path there are a bundle of python3 
packages (from the xen master branch) in the Fedora build of xen-4.12.0 at
https://src.fedoraproject.org/rpms/xen/blob/master/f/xen.python3.patch
which might be useful to apply or refer to given that RHEL 8 is loosely 
based on Fedora.

Also RHEL 8 has python36-devel and python2-devel which you might need for 
a python3 or python2 build.

Michael Young

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 135251
 build-arm64   6 xen-buildfail REGR. vs. 135251
 build-amd64-xsm   6 xen-buildfail REGR. vs. 135251
 build-amd64   6 xen-buildfail REGR. vs. 135251
 build-i386-xsm6 xen-buildfail REGR. vs. 135251
 build-i3866 xen-buildfail REGR. vs. 135251
 build-armhf   6 xen-buildfail REGR. vs. 135251

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 

Re: [Xen-devel] [PATCH] gitignore: Ignore xen.lds and asm-offsets.s for all archs

[Jan Beulich]

>>> On 24.05.19 at 02:56,  wrote:
> Instead of ignoring xen.lds and asm-offsets.s for every specific arch,
> let's instead just use gitignore's wildcard feature to ignore them for
> all archs.
> 
> Signed-off-by: Alistair Francis 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v8 27/50] x86emul: support AVX512{F, ER} reciprocal insns

[Jan Beulich]

>>> On 23.05.19 at 18:15,  wrote:
> On 15/03/2019 10:55, Jan Beulich wrote:
>> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>>
>> Note that despite the replacement of the SHA insns' table slots there's
>> no need to special case their decoding: Their insn-specific code already
>> sets op_bytes (as was required due to simd_other), and TwoOp is of no
>> relevance for legacy encoded SIMD insns.
>>
>> The raising of #UD when EVEX.L'L is 3 for AVX512ER scalar insns is done
>> to be on the safe side. The SDM does not clarify behavior there, and
>> it's even more ambiguous here (without AVX512VL in the picture).
>>
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Andrew Cooper 

Thanks, also for the others.

> Seeing as I have some ER hardware, is there an easy way to get
> GCC/binutils to emit a weird L'L field, or will this involve some manual
> opcode generation to test?

gcc does not provide any control at all, afaict. binutils allows "weird"
VEX.L or EVEX.L'L only for insns it believes ignore that field. So yes,
I'm afraid this will involve using .byte.

Jan



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

Re: [Xen-devel] [PATCH 1/3] xen: drop in_atomic()

[Jan Beulich]

>>> On 24.05.19 at 07:41,  wrote:
> On 22/05/2019 12:10, Jan Beulich wrote:
> On 22.05.19 at 11:45,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>>  
>>>  ASSERT(is_hvm_vcpu(v));
>>>  
>>> -/*
>>> - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
>>> - * such as query_size. Grant-table code currently does 
>>> copy_to/from_guest
>>> - * accesses under the big per-domain lock, which this test would 
>>> disallow.
>>> - * The test is not needed until we implement sleeping-on-waitqueue when
>>> - * we access a paged-out frame, and that's post 4.1.0 now.
>>> - */
>>> -#if 0
>>> -/*
>>> - * If the required guest memory is paged out, this function may sleep.
>>> - * Hence we bail immediately if called from atomic context.
>>> - */
>>> -if ( in_atomic() )
>>> -return HVMTRANS_unhandleable;
>>> -#endif
>> 
>> Dealing with this TODO item is of course much appreciated, but
>> should it really be deleted altogether? The big-domain-lock issue
>> is gone afair, in which case dropping the #if 0 would seem
>> possible to me, even if it's not strictly needed without the sleep-
>> on-waitqueue behavior mentioned.
> 
> I just had a look and found the following path:
> 
> do_domctl() (takes domctl_lock and hypercall_deadlock_mutex)
>   arch_do_domctl()
> raw_copy_from_guest()
>   copy_from_user_hvm()
> hvm_copy_from_guest_linear()
>   __hvm_copy()
> 
> So no, we can't do the in_atomic() test IMO.

Oh, right - that's a PVH constraint that could probably not even
be thought of that the time the comment was written. I'm still
of the opinion though that at least the still applicable part of
the comment should be kept in place. Whether this means also
keeping in_atomic() itself is then an independent question, i.e.
I wouldn't consider it overly bad if there was no implementation
in the tree, but the above still served as documentation of what
would need to be re-added. Still my preference would be for it
to be kept.

Jan



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

[Xen-devel] [linux-4.9 test] 136739: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 136249
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 136249
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 136249
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 136249
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 136249
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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 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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-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:
 linuxa5f56b52c878585b12b8bc37f737dcce4a660c64
baseline version:
 linuxffe8cffc8be1ae47c08cbc3571bed6b5b0fa53ad

Last test of basis   136249  2019-05-14 20:31:10 Z9 days
Failing since136431  2019-05-17 07:39:38 Z6 days3 attempts
Testing same since   136739  2019-05-22 04:02:35 Z2 days