Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

[Peng Fan]

Hi Julien,

Inline marked with [Peng Fan]

From: Julien Grall  
Sent: 2019年11月9日 6:44
To: Stefano Stabellini ; Andre Przywara 

Cc: Peng Fan ; Jürgen Groß ; 
julien.gr...@arm.com; xen-de...@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

Hi,

Sorry for the formatting.
On Sat, 9 Nov 2019, 04:27 Stefano Stabellini,  
wrote:
On Thu, 7 Nov 2019, Peng Fan wrote:
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
> 
> Signed-off-by: Peng Fan 

Reviewed-by: Stefano Stabellini 

To be honest, I am not sure the code is correct. A read to those registers 
should tell you the list of interrupts active. As we always return 0, this will 
not return the correct state of the GIC.

I know that returning the list of actives interrupts is complicated with the 
old vGIC, but I don't think silently ignoring it is a good idea.

The question here is why the guest accessed those registers? What is it trying 
to figure out?

[Peng Fan] I am running Linux 5.4 kernel dom0, gic_peek_irq triggers abort.



Juergen, I think this fix should be in the release (and also
backported to stable trees.)

Without an understanding of the problem, I disagree with this request (see 
above).

As an aside, the range ISPENDR  has the same issue.

[Peng Fan] Should I include this change in v2? Or develop new method to fix the 
issue?
But at least dom0 abort when boot.

Thanks,
Peng.

Cheers,






> ---
>  xen/arch/arm/vgic-v3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 422b94f902..e802f2055a 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -706,7 +706,7 @@ static int __vgic_v3_distr_common_mmio_read(const char 
> *name, struct vcpu *v,
>          goto read_as_zero;
>  
>      /* Read the active status of an IRQ via GICD/GICR is not supported */
> -    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
> +    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
>      case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>          goto read_as_zero;
>  
> -- 
> 2.16.4
> 

___
Xen-devel mailing list
mailto:Xen-devel@lists.xenproject.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.xenproject.org%2Fmailman%2Flistinfo%2Fxen-devel=02%7C01%7Cpeng.fan%40nxp.com%7C33f2e907cdc84ed0a48608d7649d359e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637088498678782239=G3FA2vefr56FeUX5QVZQwSzG22nfv1m%2F0fKIDOnfuFQ%3D=0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.12-testing test] 144007: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143190
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 143190
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 143190
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 143190

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail  like 143190
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-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-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-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 995d8b8568fe67afffdaac3012d7b990e7314d0b
baseline version:
 ovmf fb92fe9e1817a53ca0fc985447f3c534201a62fa

Last test of basis   143965  2019-11-09 20:01:24 Z2 days
Testing same since   144011  2019-11-11 11:09:14 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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
   fb92fe9e18..995d8b8568  995d8b8568fe67afffdaac3012d7b990e7314d0b -> 
xen-tested-master

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142915
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142915
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142915
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142915
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142915
 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 143993 REGR. 
vs. 142915

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds15 guest-saverestore fail in 143993 pass in 144005
 test-armhf-armhf-libvirt 19 leak-check/check fail in 143993 pass in 144005
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 143977
 test-amd64-amd64-xl-pvshim   12 guest-startfail pass in 143993

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  18 guest-localmigrate/x10 fail in 143977 like 142915
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 143993 blocked 
in 142915
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142915
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142915
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142915
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

[Sander Eikelenboom]

On 11/11/2019 16:35, Jan Beulich wrote:
> On 31.10.2019 21:48, Sander Eikelenboom wrote:
>> - The usb3 controller malfunctioning seems indeed to be a separate issue 
>> (which seems unfortunate, 
>>   because a bisect seems to become even nastier with all the intertwined 
>> pci-passthrough issues).
>>   
>>   Perhaps this one is then related to the only *once* occuring message: 
>>   (XEN) [2019-10-31 20:39:30.746] AMD-Vi: INVALID_DEV_REQUEST 
>> 0800 8a00 f8000840 00fd
>>  
>>   While in the guest it is endlessly repeating:
>>   [  231.385566] xhci_hcd :00:05.0: Max number of devices this 
>> xHCI host supports is 32.
>>   [  231.407351] usb usb1-port2: couldn't allocate usb_device
> 
> I'm uncertain whether there's a correlation: The device the Xen
> message is about is 08:00.0; please let us know what kind of device
> that is (the hypervisor log alone don't allow me to guess).
> 
> The specific type is described as "Posted write to the Interrupt/EOI
> range from an I/O device that has IntCtl=00b in the device’s DTE."
> This would make me guess 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs
> right after table allocation") is the culprit here, and I may need
> to hand you a debugging patch to gain some insight. But let me first
> take a look at sufficiently verbose lspci output from that system.
> 
> Jan
> 

Hi Jan,

When supplying "pci=nomsi" to the guest kernel, the device works fine,
and I don't get the "INVALID_DEV_REQUEST".

After reverting 1b00c16bdf, the device works fine 
and I don't get the INVALID_DEV_REQUEST, 

Below is the output of lspci -vvvknn from dom0 for 08:00.0:
- just after boot (device owned by pciback / dom0, not active yet)
- after the guests have started (owned by guest with a working device)

So it is enabling MSI-X interrupts, which is indeed different from the other 
devices I pass through which
seem to use legacy interrupts.
This also shows in the guest with a working device in /proc/interrupts:
 98:  17846  0  0  0  xen-pirq-msi-x 
xhci_hcd
 99:  0  0  0  0  xen-pirq-msi-x 
xhci_hcd
100:  0  0  0  0  xen-pirq-msi-x 
xhci_hcd
101:  0  0  0  0  xen-pirq-msi-x 
xhci_hcd
102:  0  0  0  0  xen-pirq-msi-x 
xhci_hcd

I forgot to take a snapshot of /proc/interrupts in the guest in the 
malfunctioning state.

--
Sander


just after boot (device owned by pciback / dom0, not active yet):
08:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host 
Controller [1033:0194] (rev 03) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard [1043:8413]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC 5/7] WIP:arm64:armds: Build XEN with ARM Compiler 6.6

[Stefano Stabellini]

On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> Here several ARM Compiler 6.6 issues are solved or provided a work-around:
> 
>  - Scatter file is pretty primitive, it has no feature to define symbols
>  - ARM linker defined symbols are not counted as referred if only mentioned
>in a steering file for rename or resolve, so a header file is used to
>redefine GNU linker script symbols into armlink defined symbols.
> 
>  - _srodata type clashes by type with __start_bug_frames so can not be both
>redefined as Load$$_rodata_bug_frames_0$$Base. Use resolve feature of 
> armlink
>steering file.

Why _srodata and __start_bug_frames cannot both be defined as
Load$$_rodata_bug_frames_0$$Base when actually in the case of:

> +#define __per_cpu_data_end  Load$$_bss_percpu$$Limit
> +#define __bss_end   Load$$_bss_percpu$$Limit
> +#define _endLoad$$_bss_percpu$$Limit

They are all defined as "Load$$_bss_percpu$$Limit"? And:

> +#define __init_end  Load$$_bss$$Base
> +#define __bss_start Load$$_bss$$Base

They are both defined as "Load$$_bss$$Base"? What's special about
"Load$$_rodata_bug_frames_0$$Base"?


>  - C style shift operators are missed among supported scatter file 
> expressions,
>so some needed values are hardcoded in scatter file.
> 
>  - Rename correspondent ARM Linker defined symbols to those needed by 
> `symbols` tool
>using steering file feature.
> 
>  - ARM Compiler 6.6 tools are not able to rename sections, so we still need
>GNU toolchain's objcopy for this.
> 
> Signed-off-by: Andrii Anisov 
> ---
>  xen/Rules.mk|   6 +
>  xen/arch/arm/Makefile   |  24 
>  xen/arch/arm/xen.scat.S | 266 
> 

I would strongly suggest to rename this file with something not
potentially related to scat


>  xen/arch/arm/xen.steer  |   5 +
>  xen/include/asm-arm/armds.h |  91 +++
>  5 files changed, 392 insertions(+)
>  create mode 100644 xen/arch/arm/xen.scat.S
>  create mode 100644 xen/arch/arm/xen.steer
>  create mode 100644 xen/include/asm-arm/armds.h
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 41a1c26..67bedce 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -60,6 +60,12 @@ CFLAGS += -nostdinc -fno-builtin -fno-common
>  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>  $(call cc-option-add,CFLAGS,CC,-Wvla)
>  CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> +
> +ifeq ($(armds),y)
> +CFLAGS += -nostdlibinc -nostdlib -Wno-unused-command-line-argument
> +CFLAGS += -include $(BASEDIR)/include/asm/armds.h
> +endif
> +
>  CFLAGS-$(CONFIG_DEBUG_INFO) += -g
>  CFLAGS += '-D__OBJECT_FILE__="$@"'
>  
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 70f532e..a5a3479 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -83,11 +83,16 @@ else
>  all_symbols =
>  endif
>  
> +ifeq ($(armds),y)
> +$(TARGET): $(TARGET)-syms
> + fromelf --bin $< --output $@
> +else
>  $(TARGET): $(TARGET)-syms
>   $(OBJCOPY) -O binary -S $< $@
>  ifeq ($(CONFIG_ARM_64),y)
>   ln -sf $(notdir $@)  ../../$(notdir $@).efi
>  endif
> +endif
>  
>  ifeq ($(CONFIG_LTO),y)
>  # Gather all LTO objects together
> @@ -102,6 +107,19 @@ prelink.o: $(ALL_OBJS)
>   $(LD) $(LDFLAGS) -r -o $@ $^
>  endif
>  
> +ifeq ($(armds),y)
> +$(TARGET)-syms: prelink.o xen.scat
> + armlink --scatter="xen.scat" --edit="xen.steer" --no_scanlib $(LDFLAGS) 
> prelink.o $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> + $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> + | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
> >$(@D)/.$(@F).0.S
> + $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> + armlink --scatter="xen.scat" --edit="xen.steer" --no_scanlib $(LDFLAGS) 
> prelink.o $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> + $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> + | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
> >$(@D)/.$(@F).1.S
> + $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
> + armlink --scatter="xen.scat" --edit="xen.steer" --no_scanlib 
> --symdefs="$(@D)/$(@F).map" $(LDFLAGS) prelink.o $(build_id_linker) 
> $(@D)/.$(@F).1.o -o $@
> + rm -f $(@D)/.$(@F).[0-9]*
> +else
>  $(TARGET)-syms: prelink.o xen.lds
>   $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>   $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> @@ -119,14 +137,20 @@ $(TARGET)-syms: prelink.o xen.lds
>   | $(BASEDIR)/tools/symbols --xensyms --sysv --sort \
>   >$(@D)/$(@F).map
>   rm -f $(@D)/.$(@F).[0-9]*
> +endif
>  
>  asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
>   $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
>  
> +ifeq ($(armds),y)
> +xen.scat: xen.scat.S
> + $(CC) -P -E --target=aarch64-arm-none-eabi -o $@ $<
> +else
>  xen.lds: xen.lds.S
>   $(CC) -P -E -Ui386 $(AFLAGS) -o 

Re: [Xen-devel] [RFC 7/7] arm/gic-v3: add GIC version suffix to iomem range variables

[Stefano Stabellini]

On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> ARM Compiler 6.6 has a proven bug: static data symbols, moved to an init
> section, becomes global. Thus these symbols clash with ones defined in
> gic-v2.c. The straight forward way to resolve the issue is to add the GIC
> version suffix, at least for one of the conflicting side.
> 
> Signed-off-by: Andrii Anisov 

The patch is acceptable but this seems a very serious compiler bug.
This, together with the other bug described in the previous patch, makes
me think the ARMCC is not quite ready for showtime. Do you know if there
are any later version of the compiler that don't have these problems?

I would hate to introduce these workarounds, especially the one in patch
#6, if they won't be required anymore with the next ARMCC version.



> ---
>  xen/arch/arm/gic-v3.c | 68 
> +--
>  1 file changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 0f6cbf6..f57597a 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1328,14 +1328,14 @@ static const hw_irq_controller gicv3_guest_irq_type = 
> {
>  .set_affinity = gicv3_irq_set_affinity,
>  };
>  
> -static paddr_t __initdata dbase = INVALID_PADDR;
> -static paddr_t __initdata vbase = INVALID_PADDR, vsize = 0;
> -static paddr_t __initdata cbase = INVALID_PADDR, csize = 0;
> +static paddr_t __initdata dbase_v3 = INVALID_PADDR;
> +static paddr_t __initdata vbase_v3 = INVALID_PADDR, vsize_v3 = 0;
> +static paddr_t __initdata cbase_v3 = INVALID_PADDR, csize_v3 = 0;
>  
>  /* If the GICv3 supports GICv2, initialize it */
>  static void __init gicv3_init_v2(void)
>  {
> -if ( cbase == INVALID_PADDR || vbase == INVALID_PADDR )
> +if ( cbase_v3 == INVALID_PADDR || vbase_v3 == INVALID_PADDR )
>  return;
>  
>  /*
> @@ -1343,26 +1343,26 @@ static void __init gicv3_init_v2(void)
>   * So only support GICv2 on GICv3 when the virtual CPU interface is
>   * at least GUEST_GICC_SIZE.
>   */
> -if ( vsize < GUEST_GICC_SIZE )
> +if ( vsize_v3 < GUEST_GICC_SIZE )
>  {
>  printk(XENLOG_WARNING
> "GICv3: WARNING: Not enabling support for GICv2 compat 
> mode.\n"
> "Size of GICV (%#"PRIpaddr") must at least be %#llx.\n",
> -   vsize, GUEST_GICC_SIZE);
> +   vsize_v3, GUEST_GICC_SIZE);
>  return;
>  }
>  
>  printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase 
> %#"PRIpaddr"\n",
> -   cbase, vbase);
> +   cbase_v3, vbase_v3);
>  
> -vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
> +vgic_v2_setup_hw(dbase_v3, cbase_v3, csize_v3, vbase_v3, 0);
>  }
>  
>  static void __init gicv3_ioremap_distributor(paddr_t dist_paddr)
>  {
>  if ( dist_paddr & ~PAGE_MASK )
>  panic("GICv3:  Found unaligned distributor address %"PRIpaddr"\n",
> -  dbase);
> +  dbase_v3);
>  
>  gicv3.map_dbase = ioremap_nocache(dist_paddr, SZ_64K);
>  if ( !gicv3.map_dbase )
> @@ -1375,11 +1375,11 @@ static void __init gicv3_dt_init(void)
>  int res, i;
>  const struct dt_device_node *node = gicv3_info.node;
>  
> -res = dt_device_get_address(node, 0, , NULL);
> +res = dt_device_get_address(node, 0, _v3, NULL);
>  if ( res )
>  panic("GICv3: Cannot find a valid distributor address\n");
>  
> -gicv3_ioremap_distributor(dbase);
> +gicv3_ioremap_distributor(dbase_v3);
>  
>  if ( !dt_property_read_u32(node, "#redistributor-regions",
>  _count) )
> @@ -1416,10 +1416,10 @@ static void __init gicv3_dt_init(void)
>   * provided.
>   */
>  res = dt_device_get_address(node, 1 + gicv3.rdist_count,
> -, );
> +_v3, _v3);
>  if ( !res )
>  dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
> -  , );
> +  _v3, _v3);
>  }
>  
>  static int gicv3_iomem_deny_access(const struct domain *d)
> @@ -1427,7 +1427,7 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  int rc, i;
>  unsigned long mfn, nr;
>  
> -mfn = dbase >> PAGE_SHIFT;
> +mfn = dbase_v3 >> PAGE_SHIFT;
>  nr = PFN_UP(SZ_64K);
>  rc = iomem_deny_access(d, mfn, mfn + nr);
>  if ( rc )
> @@ -1446,19 +1446,19 @@ static int gicv3_iomem_deny_access(const struct 
> domain *d)
>  return rc;
>  }
>  
> -if ( cbase != INVALID_PADDR )
> +if ( cbase_v3 != INVALID_PADDR )
>  {
> -mfn = cbase >> PAGE_SHIFT;
> -nr = PFN_UP(csize);
> +mfn = cbase_v3 >> PAGE_SHIFT;
> +nr = PFN_UP(csize_v3);
>  rc = iomem_deny_access(d, mfn, mfn + nr);
>  if ( rc )
>  return rc;
>  }
>  
> -if ( vbase != INVALID_PADDR )
> +if ( vbase_v3 != INVALID_PADDR )
>  {
> -   

Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

[Stefano Stabellini]

On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> ARM Compiler 6 has a proven bug: it compiles data only C files with
> SoftVFP attributes. This leads to a failed linkage afterwards with
> an error:
> 
> Error: L6242E: Cannot link object built_in.o as its attributes are 
> incompatible with the image attributes.
> ... A64 clashes with SoftVFP.
> 
> The known workaround is introducing some code into the affected file,
> e.g. an empty (non-static) function is enough.

Oh man, this is truly horrible.

If we really have to do this please:

- use the same dummy function name in all files
- the function should be static
- hiding the function within a #ifdef ARMCC block
- potentially hide the whole horrible hack behind a #define so that it
  would become at the call site:

 +ARMCC_DUMMY_FUNC_HACK()



> Signed-off-by: Andrii Anisov 
>
> ---
>  xen/arch/arm/platforms/brcm-raspberry-pi.c | 2 ++
>  xen/arch/arm/platforms/thunderx.c  | 2 ++
>  xen/xsm/flask/gen-policy.py| 4 
>  3 files changed, 8 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c 
> b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> index b697fa2..7ab1810 100644
> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> @@ -40,6 +40,8 @@ static const struct dt_device_match rpi4_blacklist_dev[] 
> __initconst =
>  { /* sentinel */ },
>  };
>  
> +void brcm_raspberry_pi_dummy_func(void) {}
> +
>  PLATFORM_START(rpi4, "Raspberry Pi 4")
>  .compatible = rpi4_dt_compat,
>  .blacklist_dev  = rpi4_blacklist_dev,
> diff --git a/xen/arch/arm/platforms/thunderx.c 
> b/xen/arch/arm/platforms/thunderx.c
> index 9b32a29..8015323 100644
> --- a/xen/arch/arm/platforms/thunderx.c
> +++ b/xen/arch/arm/platforms/thunderx.c
> @@ -33,6 +33,8 @@ static const struct dt_device_match 
> thunderx_blacklist_dev[] __initconst =
>  { /* sentinel */ },
>  };
>  
> +void thunderx_dummy_func(void) {}
> +
>  PLATFORM_START(thunderx, "THUNDERX")
>  .compatible = thunderx_dt_compat,
>  .blacklist_dev = thunderx_blacklist_dev,
> diff --git a/xen/xsm/flask/gen-policy.py b/xen/xsm/flask/gen-policy.py
> index c7501e4..73bf7d2 100644
> --- a/xen/xsm/flask/gen-policy.py
> +++ b/xen/xsm/flask/gen-policy.py
> @@ -21,3 +21,7 @@ sys.stdout.write("""
>  };
>  const unsigned int __initconst xsm_flask_init_policy_size = %d;
>  """ % policy_size)
> +
> +sys.stdout.write("""
> +void policy_dummy_func(void) {}
> +""")
> -- 
> 2.7.4
> 

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

[Xen-devel] [PATCH] AMD/IOMMU: Fix passthrough following c/s d7cfeb7c13e

[Andrew Cooper]

"AMD/IOMMU: don't blindly allocate interrupt remapping tables" introduces a
call at runtime from amd_iommu_add_device() to amd_iommu_set_intremap_table()
which is still marked as __init.

On one AMD Rome machine we have, this results in a crash the moment we try to
use an SR-IOV VF in a VM.

Reported-by: Jennifer Herbert 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Juergen Gross 

For 4.13.  This is a regression vs 4.12
---
 xen/drivers/passthrough/amd/iommu_map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 2859d8257e..f3fcfb9e0f 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -112,7 +112,7 @@ void amd_iommu_set_root_page_table(struct amd_iommu_dte 
*dte,
 dte->v = valid;
 }
 
-void __init amd_iommu_set_intremap_table(
+void amd_iommu_set_intremap_table(
 struct amd_iommu_dte *dte, const void *ptr,
 const struct amd_iommu *iommu, bool valid)
 {
-- 
2.11.0


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

Re: [Xen-devel] [RFC 4/7] arm/gic: Drop pointless assertions

[Stefano Stabellini]

On Wed, 6 Nov 2019, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> Also armclang complains about the condition always true,
> because `sgi` is of type enum with all its values under 16.
> 
> Signed-off-by: Andrii Anisov 

Although I am not completely opposed to this, given the choice I would
prefer to keep the ASSERTs.

Given that I would imagine that the ARM C Compiler will also complain
about many other ASSERTs, I wonder if it wouldn't be better to just
disable *all* ASSERTs when building with armcc by changing the
implementation of the ASSERT MACRO.


> ---
>  xen/arch/arm/gic.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 113655a..58c6141 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -294,8 +294,6 @@ void __init gic_init(void)
>  
>  void send_SGI_mask(const cpumask_t *cpumask, enum gic_sgi sgi)
>  {
> -ASSERT(sgi < 16); /* There are only 16 SGIs */
> -
>  gic_hw_ops->send_SGI(sgi, SGI_TARGET_LIST, cpumask);
>  }
>  
> @@ -306,15 +304,11 @@ void send_SGI_one(unsigned int cpu, enum gic_sgi sgi)
>  
>  void send_SGI_self(enum gic_sgi sgi)
>  {
> -ASSERT(sgi < 16); /* There are only 16 SGIs */
> -
>  gic_hw_ops->send_SGI(sgi, SGI_TARGET_SELF, NULL);
>  }
>  
>  void send_SGI_allbutself(enum gic_sgi sgi)
>  {
> -   ASSERT(sgi < 16); /* There are only 16 SGIs */
> -
> gic_hw_ops->send_SGI(sgi, SGI_TARGET_OTHERS, NULL);
>  }
>  
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [RFC 3/7] arm64:armds: ARM Compiler 6.6 does not accept `rx` registers naming for AArch64

[Stefano Stabellini]

On Wed, 6 Nov 2019, Jan Beulich wrote:
> On 06.11.2019 10:19, Andrii Anisov wrote:
> > --- a/xen/include/asm-arm/smccc.h
> > +++ b/xen/include/asm-arm/smccc.h
> > @@ -120,6 +120,8 @@ struct arm_smccc_res {
> >  #define __constraint_read_6 __constraint_read_5, "r" (r6)
> >  #define __constraint_read_7 __constraint_read_6, "r" (r7)
> >  
> > +#ifdef CONFIG_ARM_32
> > +
> >  #define __declare_arg_0(a0, res)\
> >  struct arm_smccc_res*___res = res;  \
> >  register unsigned long  r0 asm("r0") = (uint32_t)a0;\
> > @@ -174,6 +176,64 @@ struct arm_smccc_res {
> >  __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);   \
> >  register typeof(a7) r7 asm("r7") = __a7
> >  
> > +#else /* ARM_64 */
> > +
> > +#define __declare_arg_0(a0, res)\
> > +struct arm_smccc_res*___res = res;  \
> > +register unsigned long  r0 asm("x0") = (uint32_t)a0;\
> > +register unsigned long  r1 asm("x1");   \
> > +register unsigned long  r2 asm("x2");   \
> > +register unsigned long  r3 asm("x3")
> > +
> > +#define __declare_arg_1(a0, a1, res)\
> > +typeof(a1) __a1 = a1;   \
> > +struct arm_smccc_res*___res = res;  \
> > +register unsigned long  r0 asm("x0") = (uint32_t)a0;\
> > +register unsigned long  r1 asm("x1") = __a1;\
> > +register unsigned long  r2 asm("x2");   \
> > +register unsigned long  r3 asm("x3")
> > +
> > +#define __declare_arg_2(a0, a1, a2, res)\
> > +typeof(a1) __a1 = a1;   \
> > +typeof(a2) __a2 = a2;   \
> > +struct arm_smccc_res*___res = res;  \
> > +register unsigned long  r0 asm("x0") = (uint32_t)a0;\
> > +register unsigned long  r1 asm("x1") = __a1;\
> > +register unsigned long  r2 asm("x2") = __a2;\
> > +register unsigned long  r3 asm("x3")
> > +
> > +#define __declare_arg_3(a0, a1, a2, a3, res)\
> > +typeof(a1) __a1 = a1;   \
> > +typeof(a2) __a2 = a2;   \
> > +typeof(a3) __a3 = a3;   \
> > +struct arm_smccc_res*___res = res;  \
> > +register unsigned long  r0 asm("x0") = (uint32_t)a0;\
> > +register unsigned long  r1 asm("x1") = __a1;\
> > +register unsigned long  r2 asm("x2") = __a2;\
> > +register unsigned long  r3 asm("x3") = __a3
> > +
> > +#define __declare_arg_4(a0, a1, a2, a3, a4, res)\
> > +typeof(a4) __a4 = a4;   \
> > +__declare_arg_3(a0, a1, a2, a3, res);   \
> > +register unsigned long r4 asm("x4") = __a4
> > +
> > +#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)\
> > +typeof(a5) __a5 = a5;   \
> > +__declare_arg_4(a0, a1, a2, a3, a4, res);   \
> > +register typeof(a5) r5 asm("x5") = __a5
> > +
> > +#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)\
> > +typeof(a6) __a6 = a6;   \
> > +__declare_arg_5(a0, a1, a2, a3, a4, a5, res);   \
> > +register typeof(a6) r6 asm("x6") = __a6
> > +
> > +#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)\
> > +typeof(a7) __a7 = a7;   \
> > +__declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);   \
> > +register typeof(a7) r7 asm("x7") = __a7
> > +
> > +#endif
> 
> I'm not an Arm maintainer, so my opinion may not mean much, but
> this is way too much code duplication for my taste. Isn't all you
> need an abstraction of the "r0" etc vs "x0" etc strings? Or even
> better, can't use to the "x0" etc form with the other compilers
> (seeing that these are their architectural names when taking the
> full with registers)?

Yes, please :-)

If there is no way to get the ARM C compiler to accept "r0" on aarch64
then a #define to abstract x0/r0 would be OK.

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

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

[Stefano Stabellini]

On Mon, 11 Nov 2019, Andrew Cooper wrote:
> actypes.h and efidef.h both define BOOLEAN as unsigned char, which is buggy in
> combination with logic such as "BOOLEAN b = (a & 0x100);"  Redefine BOOLEAN as
> bool instead, which doesn't truncate.
> 
> Both also define TRUE and FALSE, with actypes.h being extra rude and replacing
> whatever exists thus far.  Drop all uses of TRUE and FALSE, replacing them
> with true/false respectively, and drop the declarations.
> 
> Also drop the pointless conditional declaration of NULL while cleaning this
> up.
> 
> Finally, correct all the comments which which were found by sed.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Stefano Stabellini 
Tested-by: Stefano Stabellini 


> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Volodymyr Babchuk 
> CC: Juergen Gross 
> 
> This is based on top of Rogers patch adjusting part of io_apic.c
> 
> Compile tested on ARM, fully texted on x86.
> 
> RFC for 4.13 - I thought I'd got all of the boolean truncation bugs back in
> 4.8 but clearly not...
> ---
>  xen/arch/x86/io_apic.c   | 12 ++--
>  xen/arch/x86/x86_64/mm.c |  2 +-
>  xen/common/kexec.c   |  6 +++---
>  xen/common/timer.c   |  4 ++--
>  xen/drivers/acpi/tables/tbfadt.c |  4 ++--
>  xen/drivers/passthrough/vtd/utils.c  |  2 +-
>  xen/include/acpi/acconfig.h  |  2 +-
>  xen/include/acpi/actypes.h   | 20 ++--
>  xen/include/asm-arm/arm64/efibind.h  |  2 +-
>  xen/include/asm-arm/regs.h   |  2 +-
>  xen/include/asm-x86/regs.h   |  2 +-
>  xen/include/asm-x86/x86_64/efibind.h |  2 +-
>  xen/include/efi/efidef.h | 11 +--
>  xen/include/xen/mm.h |  2 +-
>  xen/include/xen/sched.h  |  2 +-
>  15 files changed, 25 insertions(+), 50 deletions(-)
> 
> diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
> index 732b57995c..6517eb5ae9 100644
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -285,7 +285,7 @@ static void __io_apic_eoi(unsigned int apic, unsigned int 
> vector, unsigned int p
>  {
>  /* If vector is unknown, read it from the IO-APIC */
>  if ( vector == IRQ_VECTOR_UNASSIGNED )
> -vector = __ioapic_read_entry(apic, pin, TRUE).vector;
> +vector = __ioapic_read_entry(apic, pin, true).vector;
>  
>  *(IO_APIC_BASE(apic)+16) = vector;
>  }
> @@ -296,28 +296,28 @@ static void __io_apic_eoi(unsigned int apic, unsigned 
> int vector, unsigned int p
>  struct IO_APIC_route_entry entry;
>  bool need_to_unmask = false;
>  
> -entry = __ioapic_read_entry(apic, pin, TRUE);
> +entry = __ioapic_read_entry(apic, pin, true);
>  
>  if ( ! entry.mask )
>  {
>  /* If entry is not currently masked, mask it and make
>   * a note to unmask it later */
>  entry.mask = 1;
> -__ioapic_write_entry(apic, pin, TRUE, entry);
> +__ioapic_write_entry(apic, pin, true, entry);
>  need_to_unmask = true;
>  }
>  
>  /* Flip the trigger mode to edge and back */
>  entry.trigger = 0;
> -__ioapic_write_entry(apic, pin, TRUE, entry);
> +__ioapic_write_entry(apic, pin, true, entry);
>  entry.trigger = 1;
> -__ioapic_write_entry(apic, pin, TRUE, entry);
> +__ioapic_write_entry(apic, pin, true, entry);
>  
>  if ( need_to_unmask )
>  {
>  /* Unmask if neccesary */
>  entry.mask = 0;
> -__ioapic_write_entry(apic, pin, TRUE, entry);
> +__ioapic_write_entry(apic, pin, true, entry);
>  }
>  }
>  }
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index fa55f3474e..e9d7b80caf 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned 
> long base)
>  }
>  
>  
> -/* Returns TRUE if given descriptor is valid for GDT or LDT. */
> +/* Returns true if given descriptor is valid for GDT or LDT. */
>  int check_descriptor(const struct domain *dom, seg_desc_t *d)
>  {
>  u32 a = d->a, b = d->b;
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index a262cc5a18..8e7540f605 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -33,7 +33,7 @@
>  #include 
>  #endif
>  
> -bool_t kexecing = FALSE;
> +bool kexecing = false;
>  
>  /* Memory regions to store the per cpu register state etc. on a crash. */
>  typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
> @@ -379,7 +379,7 @@ void kexec_crash(void)
>  if ( !test_bit(KEXEC_IMAGE_CRASH_BASE + pos, _flags) )
>  return;
>  
> -kexecing = TRUE;
> +kexecing = true;
>  
>  if ( kexec_common_shutdown() != 0 )
>  return;
> @@ -395,7 +395,7 @@ 

[Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

[Andrew Cooper]

actypes.h and efidef.h both define BOOLEAN as unsigned char, which is buggy in
combination with logic such as "BOOLEAN b = (a & 0x100);"  Redefine BOOLEAN as
bool instead, which doesn't truncate.

Both also define TRUE and FALSE, with actypes.h being extra rude and replacing
whatever exists thus far.  Drop all uses of TRUE and FALSE, replacing them
with true/false respectively, and drop the declarations.

Also drop the pointless conditional declaration of NULL while cleaning this
up.

Finally, correct all the comments which which were found by sed.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Volodymyr Babchuk 
CC: Juergen Gross 

This is based on top of Rogers patch adjusting part of io_apic.c

Compile tested on ARM, fully texted on x86.

RFC for 4.13 - I thought I'd got all of the boolean truncation bugs back in
4.8 but clearly not...
---
 xen/arch/x86/io_apic.c   | 12 ++--
 xen/arch/x86/x86_64/mm.c |  2 +-
 xen/common/kexec.c   |  6 +++---
 xen/common/timer.c   |  4 ++--
 xen/drivers/acpi/tables/tbfadt.c |  4 ++--
 xen/drivers/passthrough/vtd/utils.c  |  2 +-
 xen/include/acpi/acconfig.h  |  2 +-
 xen/include/acpi/actypes.h   | 20 ++--
 xen/include/asm-arm/arm64/efibind.h  |  2 +-
 xen/include/asm-arm/regs.h   |  2 +-
 xen/include/asm-x86/regs.h   |  2 +-
 xen/include/asm-x86/x86_64/efibind.h |  2 +-
 xen/include/efi/efidef.h | 11 +--
 xen/include/xen/mm.h |  2 +-
 xen/include/xen/sched.h  |  2 +-
 15 files changed, 25 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 732b57995c..6517eb5ae9 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -285,7 +285,7 @@ static void __io_apic_eoi(unsigned int apic, unsigned int 
vector, unsigned int p
 {
 /* If vector is unknown, read it from the IO-APIC */
 if ( vector == IRQ_VECTOR_UNASSIGNED )
-vector = __ioapic_read_entry(apic, pin, TRUE).vector;
+vector = __ioapic_read_entry(apic, pin, true).vector;
 
 *(IO_APIC_BASE(apic)+16) = vector;
 }
@@ -296,28 +296,28 @@ static void __io_apic_eoi(unsigned int apic, unsigned int 
vector, unsigned int p
 struct IO_APIC_route_entry entry;
 bool need_to_unmask = false;
 
-entry = __ioapic_read_entry(apic, pin, TRUE);
+entry = __ioapic_read_entry(apic, pin, true);
 
 if ( ! entry.mask )
 {
 /* If entry is not currently masked, mask it and make
  * a note to unmask it later */
 entry.mask = 1;
-__ioapic_write_entry(apic, pin, TRUE, entry);
+__ioapic_write_entry(apic, pin, true, entry);
 need_to_unmask = true;
 }
 
 /* Flip the trigger mode to edge and back */
 entry.trigger = 0;
-__ioapic_write_entry(apic, pin, TRUE, entry);
+__ioapic_write_entry(apic, pin, true, entry);
 entry.trigger = 1;
-__ioapic_write_entry(apic, pin, TRUE, entry);
+__ioapic_write_entry(apic, pin, true, entry);
 
 if ( need_to_unmask )
 {
 /* Unmask if neccesary */
 entry.mask = 0;
-__ioapic_write_entry(apic, pin, TRUE, entry);
+__ioapic_write_entry(apic, pin, true, entry);
 }
 }
 }
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index fa55f3474e..e9d7b80caf 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned 
long base)
 }
 
 
-/* Returns TRUE if given descriptor is valid for GDT or LDT. */
+/* Returns true if given descriptor is valid for GDT or LDT. */
 int check_descriptor(const struct domain *dom, seg_desc_t *d)
 {
 u32 a = d->a, b = d->b;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index a262cc5a18..8e7540f605 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -33,7 +33,7 @@
 #include 
 #endif
 
-bool_t kexecing = FALSE;
+bool kexecing = false;
 
 /* Memory regions to store the per cpu register state etc. on a crash. */
 typedef struct { Elf_Note * start; size_t size; } crash_note_range_t;
@@ -379,7 +379,7 @@ void kexec_crash(void)
 if ( !test_bit(KEXEC_IMAGE_CRASH_BASE + pos, _flags) )
 return;
 
-kexecing = TRUE;
+kexecing = true;
 
 if ( kexec_common_shutdown() != 0 )
 return;
@@ -395,7 +395,7 @@ static long kexec_reboot(void *_image)
 {
 struct kexec_image *image = _image;
 
-kexecing = TRUE;
+kexecing = true;
 
 kexec_common_shutdown();
 machine_reboot_kexec(image);
diff --git a/xen/common/timer.c b/xen/common/timer.c
index 645206a989..29f8f40f88 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -100,7 +100,7 @@ static void 

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Lars Kurth]

On 11/11/2019, 11:03, "Stefano Stabellini"  wrote:

On Mon, 11 Nov 2019, Lars Kurth wrote:
> On 11/11/2019, 08:12, "George Dunlap"  wrote:
> 
> On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com
> > CC: george.dun...@citrix.com
> > CC: jul...@xen.org
> > CC: lars.ku...@citrix.com
> > CC: andrew.coop...@citrix.com
> > CC: ian.jack...@eu.citrix.com
> > CC: konrad.w...@oracle.com
> > CC: w...@xen.org
> > ---
> >  docs/process/backport-tag.pandoc | 23 +++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 docs/process/backport-tag.pandoc
> > 
> > diff --git a/docs/process/backport-tag.pandoc 
b/docs/process/backport-tag.pandoc
> > new file mode 100644
> > index 00..e570efdcc8
> > --- /dev/null
> > +++ b/docs/process/backport-tag.pandoc
> > @@ -0,0 +1,23 @@
> > +Backport Tag
> > +
> > +
> > +A backport tag is an optional tag in the commit message to request 
a
> > +given commit to be backported to the stable trees:
> > +
> > +Backport: all
> > +
> > +It marks a commit for being a candidate for backports to all 
relevant
> > +trees.
> > +
> > +Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> > +
> > +Maintainers request the Backport tag to be added on commit.
> > +Contributors are also welcome to mark their patches with the 
Backport
> > +tag when they deem appropriate. Maintainers will request for it to 
be
> > +removed when that is not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, 
which
> > +will still need to be evaluated by the stable tree maintainers.
> 
> The text and the idea both look good to me.

Thank you!


> But it seems kind of balkanized to put it in its own file.  Would it 
be
> better to try to make a slightly more general bit of content?  Either
> about the backport process, or about tags in general?

Yeah, it was never meant to stay in its own separate file. I thought it
would get merged into a bigger file about the whole process when it gets
submitted.


> It should be in 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
> What is currently missing is
> - Release-Acked-by
> - The new proposed tag 
> 
> But maybe we should have a master document in tree, which defines the 
tags in use
> And then I can refer to it from 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 

For now, would you like me to add the text to the wiki at

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 ?
Or would you rather do it?

No: I can do it. Just ping me when we are in agreement about the proposal
Lars

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

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

[Stefano Stabellini]

On Sat, 9 Nov 2019, Julien Grall wrote:
> On Sat, 9 Nov 2019, 04:27 Stefano Stabellini,  wrote:
>   On Thu, 7 Nov 2019, Peng Fan wrote:
>   > The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>   >
>   > Signed-off-by: Peng Fan 
> 
>   Reviewed-by: Stefano Stabellini 
> 
> 
> To be honest, I am not sure the code is correct. A read to those registers 
> should tell you the list of interrupts active. As we always
> return 0, this will not return the correct state of the GIC.
> 
> I know that returning the list of actives interrupts is complicated with the 
> old vGIC, but I don't think silently ignoring it is a good
> idea.
> The question here is why the guest accessed those registers? What is it 
> trying to figure out?

We are not going to solve the general problem at this stage. At the
moment the code:

- ignore the first register only
- print an error and return an IO_ABORT error for the other regs

For the inconsistency alone the second option is undesirable. Also it
doesn't match the write implementation, which does the same thing for
all the GICD_ISACTIVER* regs instead of having a special treatment for
the first one only. It looks like a typo in the original patch to me.

The proposed patch switches the behavior to:

- silently ignore all the GICD_ISACTIVER* regs (as proposed)

is an improvement.


>   Juergen, I think this fix should be in the release (and also
>   backported to stable trees.)
> 
> 
> Without an understanding of the problem, I disagree with this request (see 
> above).
> 
> As an aside, the range ISPENDR  has the same issue.

You meant GICD_ICPENDR, right? Yep, that one is suffering from the same
typo mistake too.

 
>   > ---
>   >  xen/arch/arm/vgic-v3.c | 2 +-
>   >  1 file changed, 1 insertion(+), 1 deletion(-)
>   >
>   > diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>   > index 422b94f902..e802f2055a 100644
>   > --- a/xen/arch/arm/vgic-v3.c
>   > +++ b/xen/arch/arm/vgic-v3.c
>   > @@ -706,7 +706,7 @@ static int __vgic_v3_distr_common_mmio_read(const 
> char *name, struct vcpu *v,
>   >          goto read_as_zero;
>   > 
>   >      /* Read the active status of an IRQ via GICD/GICR is not 
> supported */
>   > -    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
>   > +    case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
>   >      case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>   >          goto read_as_zero;
>   > 
>   > --
>   > 2.16.4
>   >
> 
>   ___
>   Xen-devel mailing list
>   Xen-devel@lists.xenproject.org
>   https://lists.xenproject.org/mailman/listinfo/xen-devel
> 
> 
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.11-testing test] 144002: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143158
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 143158
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 143158
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 143158
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 143158

Tests which did not succeed, but are not blocking:
 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-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-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-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Stefano Stabellini]

On Mon, 11 Nov 2019, Lars Kurth wrote:
> On 11/11/2019, 08:12, "George Dunlap"  wrote:
> 
> On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini 
> > CC: jbeul...@suse.com
> > CC: george.dun...@citrix.com
> > CC: jul...@xen.org
> > CC: lars.ku...@citrix.com
> > CC: andrew.coop...@citrix.com
> > CC: ian.jack...@eu.citrix.com
> > CC: konrad.w...@oracle.com
> > CC: w...@xen.org
> > ---
> >  docs/process/backport-tag.pandoc | 23 +++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 docs/process/backport-tag.pandoc
> > 
> > diff --git a/docs/process/backport-tag.pandoc 
> b/docs/process/backport-tag.pandoc
> > new file mode 100644
> > index 00..e570efdcc8
> > --- /dev/null
> > +++ b/docs/process/backport-tag.pandoc
> > @@ -0,0 +1,23 @@
> > +Backport Tag
> > +
> > +
> > +A backport tag is an optional tag in the commit message to request a
> > +given commit to be backported to the stable trees:
> > +
> > +Backport: all
> > +
> > +It marks a commit for being a candidate for backports to all relevant
> > +trees.
> > +
> > +Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> > +
> > +Maintainers request the Backport tag to be added on commit.
> > +Contributors are also welcome to mark their patches with the Backport
> > +tag when they deem appropriate. Maintainers will request for it to be
> > +removed when that is not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, which
> > +will still need to be evaluated by the stable tree maintainers.
> 
> The text and the idea both look good to me.

Thank you!


> But it seems kind of balkanized to put it in its own file.  Would it be
> better to try to make a slightly more general bit of content?  Either
> about the backport process, or about tags in general?

Yeah, it was never meant to stay in its own separate file. I thought it
would get merged into a bigger file about the whole process when it gets
submitted.


> It should be in 
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
> What is currently missing is
> - Release-Acked-by
> - The new proposed tag 
> 
> But maybe we should have a master document in tree, which defines the tags in 
> use
> And then I can refer to it from 
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
>  

For now, would you like me to add the text to the wiki at
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 ?
Or would you rather do it?___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v5 026/126] python: add commit-per-subsystem.py

[Aleksandar Markovic]

On Friday, October 11, 2019, Vladimir Sementsov-Ogievskiy <
vsement...@virtuozzo.com> wrote:

> Add script to automatically commit tree-wide changes per-subsystem.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---


Great idea!

Can you just add a comment somewhere close to the top of the file on script
usage? Or "--help" option? If you would like to be the script maintainer,
please change the MAINTAINERS too.

Reviewed-by: Aleksandar Markovic 


>
> CC: Gerd Hoffmann 
> CC: "Gonglei (Arei)" 
> CC: Eduardo Habkost 
> CC: Igor Mammedov 
> CC: Laurent Vivier 
> CC: Amit Shah 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: John Snow 
> CC: Ari Sundholm 
> CC: Pavel Dovgalyuk 
> CC: Paolo Bonzini 
> CC: Stefan Hajnoczi 
> CC: Fam Zheng 
> CC: Stefan Weil 
> CC: Ronnie Sahlberg 
> CC: Peter Lieven 
> CC: Eric Blake 
> CC: "Denis V. Lunev" 
> CC: Markus Armbruster 
> CC: Alberto Garcia 
> CC: Jason Dillaman 
> CC: Wen Congyang 
> CC: Xie Changlong 
> CC: Liu Yuan 
> CC: "Richard W.M. Jones" 
> CC: Jeff Cody 
> CC: "Marc-André Lureau" 
> CC: "Daniel P. Berrangé" 
> CC: Richard Henderson 
> CC: Greg Kurz 
> CC: "Michael S. Tsirkin" 
> CC: Marcel Apfelbaum 
> CC: Beniamino Galvani 
> CC: Peter Maydell 
> CC: "Cédric Le Goater" 
> CC: Andrew Jeffery 
> CC: Joel Stanley 
> CC: Andrew Baumann 
> CC: "Philippe Mathieu-Daudé" 
> CC: Antony Pavlov 
> CC: Jean-Christophe Dubois 
> CC: Peter Chubb 
> CC: Subbaraya Sundeep 
> CC: Eric Auger 
> CC: Alistair Francis 
> CC: "Edgar E. Iglesias" 
> CC: Stefano Stabellini 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: Paul Burton 
> CC: Aleksandar Rikalo 
> CC: Chris Wulff 
> CC: Marek Vasut 
> CC: David Gibson 
> CC: Cornelia Huck 
> CC: Halil Pasic 
> CC: Christian Borntraeger 
> CC: "Hervé Poussineau" 
> CC: Xiao Guangrong 
> CC: Aurelien Jarno 
> CC: Aleksandar Markovic 
> CC: Mark Cave-Ayland 
> CC: Jason Wang 
> CC: Laszlo Ersek 
> CC: Yuval Shaia 
> CC: Palmer Dabbelt 
> CC: Sagar Karandikar 
> CC: Bastian Koppelmann 
> CC: David Hildenbrand 
> CC: Thomas Huth 
> CC: Eric Farman 
> CC: Matthew Rosato 
> CC: Hannes Reinecke 
> CC: Michael Walle 
> CC: Artyom Tarasenko 
> CC: Stefan Berger 
> CC: Samuel Thibault 
> CC: Alex Williamson 
> CC: Tony Krowiak 
> CC: Pierre Morel 
> CC: Michael Roth 
> CC: Hailiang Zhang 
> CC: Juan Quintela 
> CC: "Dr. David Alan Gilbert" 
> CC: Luigi Rizzo 
> CC: Giuseppe Lettieri 
> CC: Vincenzo Maffione 
> CC: Jan Kiszka 
> CC: Anthony Green 
> CC: Stafford Horne 
> CC: Guan Xuetao 
> CC: Max Filippov 
> CC: qemu-bl...@nongnu.org
> CC: integrat...@gluster.org
> CC: sheep...@lists.wpkg.org
> CC: qemu-...@nongnu.org
> CC: xen-devel@lists.xenproject.org
> CC: qemu-...@nongnu.org
> CC: qemu-s3...@nongnu.org
> CC: qemu-ri...@nongnu.org
>
>  python/commit-per-subsystem.py | 204 +
>  1 file changed, 204 insertions(+)
>  create mode 100755 python/commit-per-subsystem.py
>
> diff --git a/python/commit-per-subsystem.py b/python/commit-per-subsystem.
> py
> new file mode 100755
> index 00..2ccf84cb15
> --- /dev/null
> +++ b/python/commit-per-subsystem.py
> @@ -0,0 +1,204 @@
> +#!/usr/bin/env python3
> +#
> +# Copyright (c) 2019 Virtuozzo International GmbH
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see .
> +#
> +
> +import subprocess
> +import sys
> +import os
> +import glob
> +
> +
> +def git_add(pattern):
> +subprocess.run(['git', 'add', pattern])
> +
> +
> +def git_commit(msg):
> +subprocess.run(['git', 'commit', '-m', msg], capture_output=True)
> +
> +
> +def git_changed_files():
> +ret = subprocess.check_output(['git', 'diff', '--name-only'],
> encoding='utf-8').split('\n')
> +if ret[-1] == '':
> +del ret[-1]
> +return ret
> +
> +
> +maintainers = sys.argv[1]
> +message = sys.argv[2].strip()
> +
> +subsystem = None
> +
> +remap = {
> +'Block layer core': 'block',
> +'Block Jobs': 'block',
> +'Dirty Bitmaps': 'block',
> +'Block QAPI, monitor, command line': 'block',
> +'Block I/O path': 'block',
> +'Throttling infrastructure': 'block',
> +'Architecture support': 's390x',
> +'Guest CPU Cores (KVM)': 'kvm',
> +'Guest CPU Cores (Xen)': 'xen',
> +'Guest CPU cores (TCG)': 'tcg',
> +'Network Block Device (NBD)': 'nbd',
> +'Parallel NOR Flash devices': 'pflash',
> +'Firmware configuration (fw_cfg)': 'fw_cfg',
> +'Block 

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

[Jan Beulich]

On 31.10.2019 21:48, Sander Eikelenboom wrote:
>   While in the guest it is endlessly repeating:
>   [  231.385566] xhci_hcd :00:05.0: Max number of devices this 
> xHCI host supports is 32.
>   [  231.407351] usb usb1-port2: couldn't allocate usb_device

For this one, could you try "pci=nomsi" on the Linux kernel command
line?

Jan

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

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

[Jan Beulich]

On 31.10.2019 21:48, Sander Eikelenboom wrote:
> - The usb3 controller malfunctioning seems indeed to be a separate issue 
> (which seems unfortunate, 
>   because a bisect seems to become even nastier with all the intertwined 
> pci-passthrough issues).
>   
>   Perhaps this one is then related to the only *once* occuring message: 
>   (XEN) [2019-10-31 20:39:30.746] AMD-Vi: INVALID_DEV_REQUEST 
> 0800 8a00 f8000840 00fd
>  
>   While in the guest it is endlessly repeating:
>   [  231.385566] xhci_hcd :00:05.0: Max number of devices this 
> xHCI host supports is 32.
>   [  231.407351] usb usb1-port2: couldn't allocate usb_device

I'm uncertain whether there's a correlation: The device the Xen
message is about is 08:00.0; please let us know what kind of device
that is (the hypervisor log alone don't allow me to guess).

The specific type is described as "Posted write to the Interrupt/EOI
range from an I/O device that has IntCtl=00b in the device’s DTE."
This would make me guess 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs
right after table allocation") is the culprit here, and I may need
to hand you a debugging patch to gain some insight. But let me first
take a look at sufficiently verbose lspci output from that system.

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142750

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail in 143985 pass in 144001
 test-amd64-amd64-migrupgrade 11 xen-boot/dst_host  fail pass in 143985

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 142750
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142750
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142750
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-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-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-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-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-check

[Xen-devel] [PATCH 3/3] xen/mcelog: also allow building for 32-bit kernels

[Jan Beulich]

There's no apparent reason why it can be used on 64-bit only.

Signed-off-by: Jan Beulich 

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
 
 config XEN_MCE_LOG
bool "Xen platform mcelog"
-   depends on XEN_DOM0 && X86_64 && X86_MCE
+   depends on XEN_DOM0 && X86 && X86_MCE
help
  Allow kernel fetching MCE error from Xen platform and
  converting it into Linux mcelog format for mcelog tools


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

[Xen-devel] [PATCH 2/3] xen/mcelog: add PPIN to record when available

[Jan Beulich]

This is to augment commit 3f5a7896a5 ("x86/mce: Include the PPIN in MCE
records when available").

I'm also adding "synd" and "ipid" fields to struct xen_mce, in an
attempt to keep field offsets in sync with struct mce. These two fields
won't get populated for now, though.

Signed-off-by: Jan Beulich 

--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -393,6 +393,8 @@
 #define MSR_AMD_PSTATE_DEF_BASE0xc0010064
 #define MSR_AMD64_OSVW_ID_LENGTH   0xc0010140
 #define MSR_AMD64_OSVW_STATUS  0xc0010141
+#define MSR_AMD_PPIN_CTL   0xc00102f0
+#define MSR_AMD_PPIN   0xc00102f1
 #define MSR_AMD64_LS_CFG   0xc0011020
 #define MSR_AMD64_DC_CFG   0xc0011022
 #define MSR_AMD64_BU_CFG2  0xc001102a
--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -253,6 +253,11 @@ static int convert_log(struct mc_info *m
case MSR_IA32_MCG_CAP:
m.mcgcap = g_physinfo[i].mc_msrvalues[j].value;
break;
+
+   case MSR_PPIN:
+   case MSR_AMD_PPIN:
+   m.ppin = g_physinfo[i].mc_msrvalues[j].value;
+   break;
}
 
mic = NULL;
--- a/include/xen/interface/xen-mca.h
+++ b/include/xen/interface/xen-mca.h
@@ -332,7 +332,11 @@ struct xen_mc {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_mc);
 
-/* Fields are zero when not available */
+/*
+ * Fields are zero when not available. Also, this struct is shared with
+ * userspace mcelog and thus must keep existing fields at current offsets.
+ * Only add new fields to the end of the structure
+ */
 struct xen_mce {
__u64 status;
__u64 misc;
@@ -353,6 +357,9 @@ struct xen_mce {
__u32 socketid; /* CPU socket ID */
__u32 apicid;   /* CPU initial apic ID */
__u64 mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
+   __u64 synd; /* MCA_SYND MSR: only valid on SMCA systems */
+   __u64 ipid; /* MCA_IPID MSR: only valid on SMCA systems */
+   __u64 ppin; /* Protected Processor Inventory Number */
 };
 
 /*

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

[Xen-devel] [PATCH 1/3] xen/mcelog: drop __MC_MSR_MCGCAP

[Jan Beulich]

It has never been part of Xen's public interface, and there's therefore
no guarantee for MCG_CAP's value to always be present in array entry 0.

Signed-off-by: Jan Beulich 

--- a/drivers/xen/mcelog.c
+++ b/drivers/xen/mcelog.c
@@ -222,7 +222,7 @@ static int convert_log(struct mc_info *m
struct mcinfo_global *mc_global;
struct mcinfo_bank *mc_bank;
struct xen_mce m;
-   uint32_t i;
+   unsigned int i, j;
 
mic = NULL;
x86_mcinfo_lookup(, mi, MC_TYPE_GLOBAL);
@@ -248,7 +248,12 @@ static int convert_log(struct mc_info *m
m.socketid = g_physinfo[i].mc_chipid;
m.cpu = m.extcpu = g_physinfo[i].mc_cpunr;
m.cpuvendor = (__u8)g_physinfo[i].mc_vendor;
-   m.mcgcap = g_physinfo[i].mc_msrvalues[__MC_MSR_MCGCAP].value;
+   for (j = 0; j < g_physinfo[i].mc_nmsrvals; ++j)
+   switch (g_physinfo[i].mc_msrvalues[j].reg) {
+   case MSR_IA32_MCG_CAP:
+   m.mcgcap = g_physinfo[i].mc_msrvalues[j].value;
+   break;
+   }
 
mic = NULL;
x86_mcinfo_lookup(, mi, MC_TYPE_BANK);
--- a/include/xen/interface/xen-mca.h
+++ b/include/xen/interface/xen-mca.h
@@ -183,7 +183,6 @@ struct mc_info {
 DEFINE_GUEST_HANDLE_STRUCT(mc_info);
 
 #define __MC_MSR_ARRAYSIZE 8
-#define __MC_MSR_MCGCAP 0
 #define __MC_NMSRS 1
 #define MC_NCAPS 7
 struct mcinfo_logical_cpu {


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

[Xen-devel] [PATCH 0/3] xen/mcelog: assorted adjustments

[Jan Beulich]

The 1st change is simple cleanup, noticed while preparing for the
2nd patch, which presents the consumer of the interface extension
proposed in
https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00377.html.
The 3rd patch is sort of optional, considering that 32-bit Xen
support is slated to be phased out of the kernel.

1: drop __MC_MSR_MCGCAP
2: add PPIN to record when available
3: also allow building for 32-bit kernels

Jan

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

[Xen-devel] [PATCH 2/2] x86/Xen/32: simplify xen_iret_crit_fixup's ring check

[Jan Beulich]

This can be had with two instead of six insns, by just checking the high
CS.RPL bit.

Also adjust the comment - there would be no #GP in the mentioned cases,
as there's no segment limit violation or alike. Instead there'd be #PF,
but that one reports the target EIP of said branch, not the address of
the branch insn itself.

Signed-off-by: Jan Beulich 
---
An alternative would be to keep using SEGMENT_RPL_MASK, but follow it
with "jpe".

--- a/arch/x86/xen/xen-asm_32.S
+++ b/arch/x86/xen/xen-asm_32.S
@@ -153,22 +153,15 @@ hyper_iret:
  * it's still on stack), we need to restore its value here.
  */
 ENTRY(xen_iret_crit_fixup)
-   pushl %ecx
/*
 * Paranoia: Make sure we're really coming from kernel space.
 * One could imagine a case where userspace jumps into the
 * critical range address, but just before the CPU delivers a
-* GP, it decides to deliver an interrupt instead.  Unlikely?
-* Definitely.  Easy to avoid?  Yes.  The Intel documents
-* explicitly say that the reported EIP for a bad jump is the
-* jump instruction itself, not the destination, but some
-* virtual environments get this wrong.
+* PF, it decides to deliver an interrupt instead.  Unlikely?
+* Definitely.  Easy to avoid?  Yes.
 */
-   movl 3*4(%esp), %ecx/* nested CS */
-   andl $SEGMENT_RPL_MASK, %ecx
-   cmpl $USER_RPL, %ecx
-   popl %ecx
-   je 2f
+   testb $2, 2*4(%esp) /* nested CS */
+   jnz 2f
 
/*
 * If eip is before iret_restore_end then stack


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

[Xen-devel] [PATCH 1/2] x86/Xen/32: make xen_iret_crit_fixup independent of frame layout

[Jan Beulich]

Now that SS:ESP always get saved by SAVE_ALL, this also needs to be
accounted for in xen_iret_crit_fixup. Otherwise the old_ax value gets
interpreted as EFLAGS, and hence VM86 mode appears to be active all
the time, leading to random "vm86_32: no user_vm86: BAD" log messages
alongside processes randomly crashing.

Since following the previous model (sitting after SAVE_ALL) would
further complicate the code _and_ retain the dependency of
xen_iret_crit_fixup on frame manipulations done by entry_32.S, switch
things around and do the adjustment ahead of SAVE_ALL.

Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Jan Beulich 

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1341,11 +1341,6 @@ END(spurious_interrupt_bug)
 
 #ifdef CONFIG_XEN_PV
 ENTRY(xen_hypervisor_callback)
-   pushl   $-1 /* orig_ax = -1 => not a system 
call */
-   SAVE_ALL
-   ENCODE_FRAME_POINTER
-   TRACE_IRQS_OFF
-
/*
 * Check to see if we got the event in the critical
 * region in xen_iret_direct, after we've reenabled
@@ -1353,16 +1348,17 @@ ENTRY(xen_hypervisor_callback)
 * iret instruction's behaviour where it delivers a
 * pending interrupt when enabling interrupts:
 */
-   movlPT_EIP(%esp), %eax
-   cmpl$xen_iret_start_crit, %eax
+   cmpl$xen_iret_start_crit, (%esp)
jb  1f
-   cmpl$xen_iret_end_crit, %eax
+   cmpl$xen_iret_end_crit, (%esp)
jae 1f
-
-   jmp xen_iret_crit_fixup
-
-ENTRY(xen_do_upcall)
-1: mov %esp, %eax
+   callxen_iret_crit_fixup
+1:
+   pushl   $-1 /* orig_ax = -1 => not a system 
call */
+   SAVE_ALL
+   ENCODE_FRAME_POINTER
+   TRACE_IRQS_OFF
+   mov %esp, %eax
callxen_evtchn_do_upcall
 #ifndef CONFIG_PREEMPTION
callxen_maybe_preempt_hcall
--- a/arch/x86/xen/xen-asm_32.S
+++ b/arch/x86/xen/xen-asm_32.S
@@ -126,10 +126,9 @@ hyper_iret:
.globl xen_iret_start_crit, xen_iret_end_crit
 
 /*
- * This is called by xen_hypervisor_callback in entry.S when it sees
+ * This is called by xen_hypervisor_callback in entry_32.S when it sees
  * that the EIP at the time of interrupt was between
- * xen_iret_start_crit and xen_iret_end_crit.  We're passed the EIP in
- * %eax so we can do a more refined determination of what to do.
+ * xen_iret_start_crit and xen_iret_end_crit.
  *
  * The stack format at this point is:
  * 
@@ -138,34 +137,23 @@ hyper_iret:
  *  eflags }  outer exception info
  *  cs }
  *  eip}
- *  <- edi (copy dest)
- *  eax:  outer eax if it hasn't been restored
  * 
- *  eflags }  nested exception info
- *  cs }   (no ss/esp because we're nested
- *  eip}from the same ring)
- *  orig_eax   }<- esi (copy src)
- *  - - - - - - - -
- *  fs }
- *  es }
- *  ds }  SAVE_ALL state
- *  eax}
- *   : :
- *  ebx}<- esp
+ *  eax:  outer eax if it hasn't been restored
  * 
+ *  eflags }
+ *  cs }  nested exception info
+ *  eip}
+ *  return address : (into xen_hypervisor_callback)
  *
- * In order to deliver the nested exception properly, we need to shift
- * everything from the return addr up to the error code so it sits
- * just under the outer exception info.  This means that when we
- * handle the exception, we do it in the context of the outer
- * exception rather than starting a new one.
+ * In order to deliver the nested exception properly, we need to discard the
+ * nested exception frame such that when we handle the exception, we do it
+ * in the context of the outer exception rather than starting a new one.
  *
- * The only caveat is that if the outer eax hasn't been restored yet
- * (ie, it's still on stack), we need to insert its value into the
- * SAVE_ALL state before going on, since it's usermode state which we
- * eventually need to restore.
+ * The only caveat is that if the outer eax hasn't been restored yet (i.e.
+ * it's still on stack), we need to restore its value here.
  */
 ENTRY(xen_iret_crit_fixup)
+   pushl %ecx
/*
 * Paranoia: Make sure we're really coming from kernel space.
 * One could imagine a case where userspace jumps into the
@@ -176,32 +164,26 @@ ENTRY(xen_iret_crit_fixup)
 * jump instruction itself, not the destination, but some
 * virtual environments get this wrong.
 */
-   movl PT_CS(%esp), %ecx
+   movl 3*4(%esp), %ecx/* nested CS */
andl $SEGMENT_RPL_MASK, %ecx
cmpl $USER_RPL, %ecx
+   popl %ecx
je 2f
 
-   

[Xen-devel] [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments

[Jan Beulich]

The first patch here fixes another regression from 3c88c692c287
("x86/stackframe/32: Provide consistent pt_regs"), besides the
one already addressed by
https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
The second patch is a minimal bit of cleanup on top.

1: make xen_iret_crit_fixup independent of frame layout
2: simplify xen_iret_crit_fixup's ring check

Jan

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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Lars Kurth]

On 11/11/2019, 08:12, "George Dunlap"  wrote:

On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.com
> CC: jul...@xen.org
> CC: lars.ku...@citrix.com
> CC: andrew.coop...@citrix.com
> CC: ian.jack...@eu.citrix.com
> CC: konrad.w...@oracle.com
> CC: w...@xen.org
> ---
>  docs/process/backport-tag.pandoc | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 docs/process/backport-tag.pandoc
> 
> diff --git a/docs/process/backport-tag.pandoc 
b/docs/process/backport-tag.pandoc
> new file mode 100644
> index 00..e570efdcc8
> --- /dev/null
> +++ b/docs/process/backport-tag.pandoc
> @@ -0,0 +1,23 @@
> +Backport Tag
> +
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +Backport: all
> +
> +It marks a commit for being a candidate for backports to all relevant
> +trees.
> +
> +Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +Maintainers request the Backport tag to be added on commit.
> +Contributors are also welcome to mark their patches with the Backport
> +tag when they deem appropriate. Maintainers will request for it to be
> +removed when that is not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.

The text and the idea both look good to me.

But it seems kind of balkanized to put it in its own file.  Would it be
better to try to make a slightly more general bit of content?  Either
about the backport process, or about tags in general?

It should be in 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
What is currently missing is
- Release-Acked-by
- The new proposed tag 

But maybe we should have a master document in tree, which defines the tags in 
use
And then I can refer to it from 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch.3F
 

Regards
Lars


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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[George Dunlap]

On 11/8/19 7:09 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.com
> CC: jul...@xen.org
> CC: lars.ku...@citrix.com
> CC: andrew.coop...@citrix.com
> CC: ian.jack...@eu.citrix.com
> CC: konrad.w...@oracle.com
> CC: w...@xen.org
> ---
>  docs/process/backport-tag.pandoc | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 docs/process/backport-tag.pandoc
> 
> diff --git a/docs/process/backport-tag.pandoc 
> b/docs/process/backport-tag.pandoc
> new file mode 100644
> index 00..e570efdcc8
> --- /dev/null
> +++ b/docs/process/backport-tag.pandoc
> @@ -0,0 +1,23 @@
> +Backport Tag
> +
> +
> +A backport tag is an optional tag in the commit message to request a
> +given commit to be backported to the stable trees:
> +
> +Backport: all
> +
> +It marks a commit for being a candidate for backports to all relevant
> +trees.
> +
> +Backport: 4.9+
> +
> +It marks a commit for being a candidate for backports to all stable
> +trees from 4.9 onward.
> +
> +Maintainers request the Backport tag to be added on commit.
> +Contributors are also welcome to mark their patches with the Backport
> +tag when they deem appropriate. Maintainers will request for it to be
> +removed when that is not the case.
> +
> +Please note that the Backport tag is a **request** for backport, which
> +will still need to be evaluated by the stable tree maintainers.

The text and the idea both look good to me.

But it seems kind of balkanized to put it in its own file.  Would it be
better to try to make a slightly more general bit of content?  Either
about the backport process, or about tags in general?

(This would simply be renaming the file; not expecting you to generate
extra content.)

 -George

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

Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history

[Ian Jackson]

Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and 
restore host history"):
> /me is ducking under the table ;)
> Seems to be quite a lot of intracate Perl, I never was a prince of Perl
> and that hasn't got any better by not using it actively the past years.

Heh.  Although it's generally not supposed to be intricate.  I have
tried to keep it fairly straightforward.

> Not really, but especially applying style to alternating rows is now
> quite simple with pseudo classes:
> 
>  tr:nth-child(even){
>background-color: grey;
>  }
> 
>  tr:nth-child(even){
>background-color: white;
>  }
> 
> You could stuff this in a  ... ,
> so you don't have to repeat this every row for the common case.
> For any special cases you could overrule based on class.
> I happen to find it one of the most useful CSS features.

Interesting.  Mmm.  (Although your vignette above ought to have an
`odd' in it I think...)

> > Maybe, but currently the archaeology algorithm is not expressed
> > entirely in SQL so it couldn't be a materialised view.  And converting
> > it to SQL would be annoying because SQL is a rather poor programming
> > language.
> 
> It is a poor programming language, but it is very good at retrieving and
> modifying data. Sometimes it takes some effort to wrap your head around
> the way you have to specify what data you want and in what for, without
> being to explicit in how it is supposed to be retrieved.

Indeed so.

> If I remember correctly Postgres is being used, perhaps there is stull
> some relatively low hanging fruit when analyzing the performance of the
> queries you run at the actual data.

Yes.  One of the biggest problems is I really want to make an index on
runvar *values*.  But if I do that then routine runvar updates have to
update that index.  So what I want is a partial index but the rows of
runvars which are indexed ought to be controlled by the corresponding
row of the flights table.

I am considering denormalising this by including a `finalised' bit in
the runvars table.  But not now...

> I will take a look at the code somewhere this or next week and see if I
> can get any familiarity with it and perhaps end up with some contributions.

All contributions and suggestions are welcome.

Regards,
Ian.

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

Re: [Xen-devel] [PATCH][next] xen/gntdev: remove redundant non-zero check on ret

[Colin Ian King]

On 11/11/2019 13:17, Jürgen Groß wrote:
> On 11.11.19 13:31, Colin Ian King wrote:
>> On 11/11/2019 12:25, Jürgen Groß wrote:
>>> On 11.11.19 13:20, Colin King wrote:
 From: Colin Ian King 

 The non-zero check on ret is always going to be false because
 ret was initialized as zero and the only place it is set to
 non-zero contains a return path before the non-zero check. Hence
 the check is redundant and can be removed.
>>>
>>> Which version did you patch against? In current master the above
>>> statement is not true.
>>
>> against today's linux-next
> 
> Ah, okay, this is likely the result of the recent mm-notifier patch
> series. I'll put this patch on hold until the recent patches have
> hit master.

Cool, thanks!
> 
> 
> Juergen


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

Re: [Xen-devel] [PATCH][next] xen/gntdev: remove redundant non-zero check on ret

[Jürgen Groß]

On 11.11.19 13:31, Colin Ian King wrote:

On 11/11/2019 12:25, Jürgen Groß wrote:

On 11.11.19 13:20, Colin King wrote:

From: Colin Ian King 

The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path before the non-zero check. Hence
the check is redundant and can be removed.


Which version did you patch against? In current master the above
statement is not true.


against today's linux-next


Ah, okay, this is likely the result of the recent mm-notifier patch
series. I'll put this patch on hold until the recent patches have
hit master.


Juergen

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

Re: [Xen-devel] [PATCH][next] xen/gntdev: remove redundant non-zero check on ret

[Colin Ian King]

On 11/11/2019 12:25, Jürgen Groß wrote:
> On 11.11.19 13:20, Colin King wrote:
>> From: Colin Ian King 
>>
>> The non-zero check on ret is always going to be false because
>> ret was initialized as zero and the only place it is set to
>> non-zero contains a return path before the non-zero check. Hence
>> the check is redundant and can be removed.
> 
> Which version did you patch against? In current master the above
> statement is not true.

against today's linux-next

Colin
> 
> 
> Juergen
> 
>>
>> Addresses-Coverity: ("Logically dead code")
>> Signed-off-by: Colin Ian King 
>> ---
>>   drivers/xen/gntdev.c | 5 -
>>   1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
>> index 10cc5e9e612a..07d80b176118 100644
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@ -524,11 +524,6 @@ static int gntdev_open(struct inode *inode,
>> struct file *flip)
>>   }
>>   #endif
>>   -    if (ret) {
>> -    kfree(priv);
>> -    return ret;
>> -    }
>> -
>>   flip->private_data = priv;
>>   #ifdef CONFIG_XEN_GRANT_DMA_ALLOC
>>   priv->dma_dev = gntdev_miscdev.this_device;
>>
> 


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

Re: [Xen-devel] [PATCH][next] xen/gntdev: remove redundant non-zero check on ret

[Jürgen Groß]

On 11.11.19 13:20, Colin King wrote:

From: Colin Ian King 

The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path before the non-zero check. Hence
the check is redundant and can be removed.


Which version did you patch against? In current master the above
statement is not true.


Juergen



Addresses-Coverity: ("Logically dead code")
Signed-off-by: Colin Ian King 
---
  drivers/xen/gntdev.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 10cc5e9e612a..07d80b176118 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -524,11 +524,6 @@ static int gntdev_open(struct inode *inode, struct file 
*flip)
}
  #endif
  
-	if (ret) {

-   kfree(priv);
-   return ret;
-   }
-
flip->private_data = priv;
  #ifdef CONFIG_XEN_GRANT_DMA_ALLOC
priv->dma_dev = gntdev_miscdev.this_device;




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

Re: [Xen-devel] [PATCH v2] build: provide option to disambiguate symbol names

[Wei Liu]

On Fri, Nov 08, 2019 at 12:18:40PM +0100, Jan Beulich wrote:
> The .file assembler directives generated by the compiler do not include
> any path components (gcc) or just the ones specified on the command line
> (clang, at least version 5), and hence multiple identically named source
> files (in different directories) may produce identically named static
> symbols (in their kallsyms representation). The binary diffing algorithm
> used by xen-livepatch, however, depends on having unique symbols.
> 
> Make the ENFORCE_UNIQUE_SYMBOLS Kconfig option control the (build)
> behavior, and if enabled use objcopy to prepend the (relative to the
> xen/ subdirectory) path to the compiler invoked STT_FILE symbols. Note
> that this build option is made no longer depend on LIVEPATCH, but merely
> defaults to its setting now.
> 
> Conditionalize explicit .file directive insertion in C files where it
> exists just to disambiguate names in a less generic manner; note that
> at the same time the redundant emission of STT_FILE symbols gets
> suppressed for clang. Assembler files as well as multiply compiled C
> ones using __OBJECT_FILE__ are left alone for the time being.
> 
> Since we now expect there not to be any duplicates anymore, also don't
> force the selection of the option to 'n' anymore in allrandom.config.
> Similarly COVERAGE no longer suppresses duplicate symbol warnings if
> enforcement is in effect, which in turn allows
> SUPPRESS_DUPLICATE_SYMBOL_WARNINGS to simply depend on
> !ENFORCE_UNIQUE_SYMBOLS.
> 
> 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

[Xen-devel] [PATCH][next] xen/gntdev: remove redundant non-zero check on ret

[Colin King]

From: Colin Ian King 

The non-zero check on ret is always going to be false because
ret was initialized as zero and the only place it is set to
non-zero contains a return path before the non-zero check. Hence
the check is redundant and can be removed.

Addresses-Coverity: ("Logically dead code")
Signed-off-by: Colin Ian King 
---
 drivers/xen/gntdev.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 10cc5e9e612a..07d80b176118 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -524,11 +524,6 @@ static int gntdev_open(struct inode *inode, struct file 
*flip)
}
 #endif
 
-   if (ret) {
-   kfree(priv);
-   return ret;
-   }
-
flip->private_data = priv;
 #ifdef CONFIG_XEN_GRANT_DMA_ALLOC
priv->dma_dev = gntdev_miscdev.this_device;
-- 
2.20.1


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

Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history

[Sander Eikelenboom]

On 11/11/2019 12:00, Ian Jackson wrote:
> Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up 
> and restore host history"):
>> Not mend to bike shed, so just for consideration:
> 
> Suggestions are very welcome.  Be careful, I'm still looking for a
> co-maintainer :-).
/me is ducking under the table ;)
Seems to be quite a lot of intracate Perl, I never was a prince of Perl
and that hasn't got any better by not using it actively the past years.

>> - Have you considered (inline) css for the background colouring, or does
>>   it have to be html only  ?
> 
> There is no particular reason why it shouldn't be CSS.  Is there a
> reason why doing it in html causes problems for you ?

Not really, but especially applying style to alternating rows is now
quite simple with pseudo classes:

 tr:nth-child(even){
   background-color: grey;
 }

 tr:nth-child(even){
   background-color: white;
 }

You could stuff this in a  ... ,
so you don't have to repeat this every row for the common case.
For any special cases you could overrule based on class.
I happen to find it one of the most useful CSS features.

https://www.w3.org/wiki/CSS/Selectors/pseudo-classes/:nth-child

> The background colours for the cells are made with
>   report_altcolour
>   report_altchangecolour
> in Osstest/Executive.pm.
> 
> report_altcolour returns something that can be put into an element
> open tag, given a definite indication of whether the colour should be
> paler or darker.
> 
> report_altchangecolour is used to produce background colours which
> change when the value in the cell changes.
> 
> I think it would be easy to replace bgcolour= with some appropriate
> style= and some CSS.  Patches - even very rough ones - welcome.
> 
>> - And for caching perhaps a materialized view with aggregated data only
>>   refreshed at a more convient time could perhaps help at the database
>>   level ?
> 
> Maybe, but currently the archaeology algorithm is not expressed
> entirely in SQL so it couldn't be a materialised view.  And converting
> it to SQL would be annoying because SQL is a rather poor programming
> language.

It is a poor programming language, but it is very good at retrieving and
modifying data. Sometimes it takes some effort to wrap your head around
the way you have to specify what data you want and in what for, without
being to explicit in how it is supposed to be retrieved.

> It might be possible to, instead, have table(s) containing archaeology
> results.  I hadn't really properly considered that possibility.  That
> might well have been a better approach.  So thank you for your helpful
> prompt.  I will definitely bear this in mind for the future.

If I remember correctly Postgres is being used, perhaps there is stull
some relatively low hanging fruit when analyzing the performance of the
queries you run at the actual data.

> I'm not sure I feel like reengineering this particular series at this
> time, though.  One reason (apart from that I've done it like this now)
> is that the current approach has the advantage that it doesn't need a
> DB schema change.  I have a system for doing schema changes but they
> add risk and I don't want to do that in the Xen release freeze.

I understand, and I concur that that is probably the best at the moment.

I will take a look at the code somewhere this or next week and see if I
can get any familiarity with it and perhaps end up with some contributions.

--
Sander

> Regards,
> Ian.

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

[Xen-devel] [OSSTEST PATCH 1/2] all guest creation: Pause 10s to work around libxl/blkback races

[Ian Jackson]

In 1d3a97b06d2c
  xl guest creation: Pause 10s to work around libxl/blkback races
we added a 10s delay to work around a race bug in Linux blkback.

This was intended to be used in combination with ea6626f7edd9
  guest_prepare_disk: Only do the umount if we set an env var
after which it is only xl which is vulnerable to this race.
But that commit was wrong, so we must revert it.  After we do
that the sleep in the xl driver will come too late.

So, move the 10s sleep from the osstest xl and libvirt drivers to the
general guest preparation step, right next to where the affected lv in
use check is.

This is still a bodge, unfortunately.

CC: Jürgen Groß 
CC: Wei Liu 
CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm   | 2 ++
 Osstest/Toolstack/libvirt.pm | 1 -
 Osstest/Toolstack/xl.pm  | 1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 9c99ee17..f2baa7c2 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1938,6 +1938,8 @@ sub guest_create_paused ($) {
 sub guest_prepare_disk ($) {
 my ($gho) = @_;
 
+sleep(10);
+
 guest_umount_lv($gho->{Host}, $gho)
if $ENV{'OSSTEST_GUEST_DISK_MOUNT_CLEANUP'};
 
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 23c76cc0..e817f5b4 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -55,7 +55,6 @@ sub create ($$) {
 my $lcfg = $cfg;
 $lcfg =~ s,/,-,g;
 $lcfg = hostnamepath($ho)."--$lcfg";
-sleep(10);
 target_cmd_root($ho, "virsh domxml-from-native xen-xl $cfg > $cfg.xml", 
30);
 target_getfile_root($ho,60,"$cfg.xml", "$stash/$lcfg");
 target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 517b0f4d..85972753 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -43,7 +43,6 @@ sub destroy ($$) {
 sub _create ($$$) {
 my ($self,$gho,$options) = @_;
 my $cfg = $gho->{CfgPath};
-sleep(10);
 target_cmd_root($self->{Host},
$self->{_VerboseCommand}." create $options $cfg", 100);
 }
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 2/2] Revert "guest_prepare_disk: Only do the umount if we set an env var"

[Ian Jackson]

This reverts commit ea6626f7edd9eb40a3510eaf6816a77cac4f63d0.

Contrary to the assertions in the commit message, this unmount etc. is
actually used by some tests.  So removing it breaks things.

Now, we have a different workaround: a 10s sleep before we attempt the
umount.  The combination of
  ea6626f7 guest_prepare_disk: Only do the umount if we set an env var
  1d3a97b0 xl guest creation: Pause 10s to work around libxl/blkback races
  3a208c18 all guest creation: Pause 10s to work around libxl/blkback races
and this revert is simply this:

  @@ -1938,6 +1938,8 @@ sub guest_create_paused ($) {
   sub guest_prepare_disk ($) {
   my ($gho) = @_;

  +sleep(10);
  +
   guest_umount_lv($gho->{Host}, $gho);

   return if ($gho->{Diskfmt} // 'none') eq "none";

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f2baa7c2..44f01a86 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1940,8 +1940,7 @@ sub guest_prepare_disk ($) {
 
 sleep(10);
 
-guest_umount_lv($gho->{Host}, $gho)
-   if $ENV{'OSSTEST_GUEST_DISK_MOUNT_CLEANUP'};
+guest_umount_lv($gho->{Host}, $gho);
 
 return if ($gho->{Diskfmt} // 'none') eq "none";
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Wei Liu]

On Fri, Nov 08, 2019 at 11:09:52AM -0800, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history

[Ian Jackson]

Sander Eikelenboom writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and 
restore host history"):
> Not mend to bike shed, so just for consideration:

Suggestions are very welcome.  Be careful, I'm still looking for a
co-maintainer :-).

> - Have you considered (inline) css for the background colouring, or does
>   it have to be html only  ?

There is no particular reason why it shouldn't be CSS.  Is there a
reason why doing it in html causes problems for you ?

The background colours for the cells are made with
  report_altcolour
  report_altchangecolour
in Osstest/Executive.pm.

report_altcolour returns something that can be put into an element
open tag, given a definite indication of whether the colour should be
paler or darker.

report_altchangecolour is used to produce background colours which
change when the value in the cell changes.

I think it would be easy to replace bgcolour= with some appropriate
style= and some CSS.  Patches - even very rough ones - welcome.

> - And for caching perhaps a materialized view with aggregated data only
>   refreshed at a more convient time could perhaps help at the database
>   level ?

Maybe, but currently the archaeology algorithm is not expressed
entirely in SQL so it couldn't be a materialised view.  And converting
it to SQL would be annoying because SQL is a rather poor programming
language.

It might be possible to, instead, have table(s) containing archaeology
results.  I hadn't really properly considered that possibility.  That
might well have been a better approach.  So thank you for your helpful
prompt.  I will definitely bear this in mind for the future.

I'm not sure I feel like reengineering this particular series at this
time, though.  One reason (apart from that I've done it like this now)
is that the current approach has the advantage that it doesn't need a
DB schema change.  I have a system for doing schema changes but they
add risk and I don't want to do that in the Xen release freeze.

Regards,
Ian.

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

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

[Ian Jackson]

Stefano Stabellini writes ("[PATCH] Introduce a description of a new optional 
tag for Backports"):
> Signed-off-by: Stefano Stabellini 

+2

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH for-4.13 v3] x86/passthrough: fix migration of MSI when using posted interrupts

[Jan Beulich]

On 08.11.2019 14:34, Roger Pau Monne wrote:
> When using posted interrupts and the guest migrates MSI from vCPUs Xen
> needs to flush any pending PIRR vectors on the previous vCPU, or else
> those vectors could get wrongly injected at a later point when the MSI
> fields are already updated.
> 
> Rename sync_pir_to_irr to vlapic_sync_pir_to_irr and export it so it
> can be called when updating the binding of physical interrupts to
> guests.
> 
> Note that PIRR is synced to IRR both in pt_irq_destroy_bind and
> pt_irq_create_bind when the interrupt delivery data is being updated.
> 
> Also store the vCPU ID in multi-destination mode when using posted
> interrupts so that the interrupt is always injected to a known vCPU in
> order to be able to flush the PIRR when modifying the binding.
> 
> Reported-by: Joe Jin 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Joe Jin 
> Cc: Juergen Gross 
> ---
> I would like to see a bug fix for this issue in 4.13. The fix here only
> affects posted interrupts, hence I think the risk of breaking anything
> else is low.
> ---
> Changes since v2:
>  - Also sync PIRR with IRR when using CPU posted interrupts.
>  - Force the selection of a specific vCPU when using posted interrupts
>for multi-dest.
>  - Change vmsi_deliver_pirq to honor dest_vcpu_id.
> 
> Changes since v1:
>  - Store the vcpu id also in multi-dest mode if the interrupt is bound
>to a vcpu for posted delivery.
>  - s/#if/#ifdef/.
> ---
>  xen/arch/x86/hvm/vlapic.c|  6 +++---
>  xen/arch/x86/hvm/vmsi.c  | 11 ++-
>  xen/drivers/passthrough/io.c | 29 +++--
>  xen/include/asm-x86/hvm/vlapic.h |  2 ++
>  4 files changed, 38 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 9466258d6f..d255ad8db7 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -106,7 +106,7 @@ static void vlapic_clear_irr(int vector, struct vlapic 
> *vlapic)
>  vlapic_clear_vector(vector, >regs->data[APIC_IRR]);
>  }
>  
> -static void sync_pir_to_irr(struct vcpu *v)
> +void vlapic_sync_pir_to_irr(struct vcpu *v)
>  {
>  if ( hvm_funcs.sync_pir_to_irr )
>  alternative_vcall(hvm_funcs.sync_pir_to_irr, v);
> @@ -114,7 +114,7 @@ static void sync_pir_to_irr(struct vcpu *v)
>  
>  static int vlapic_find_highest_irr(struct vlapic *vlapic)
>  {
> -sync_pir_to_irr(vlapic_vcpu(vlapic));
> +vlapic_sync_pir_to_irr(vlapic_vcpu(vlapic));
>  
>  return vlapic_find_highest_vector(>regs->data[APIC_IRR]);
>  }
> @@ -1493,7 +1493,7 @@ static int lapic_save_regs(struct vcpu *v, 
> hvm_domain_context_t *h)
>  if ( !has_vlapic(v->domain) )
>  return 0;
>  
> -sync_pir_to_irr(v);
> +vlapic_sync_pir_to_irr(v);
>  
>  return hvm_save_entry(LAPIC_REGS, v->vcpu_id, h, vcpu_vlapic(v)->regs);
>  }
> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index 6597d9f719..fe488ccc7d 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -118,7 +118,16 @@ void vmsi_deliver_pirq(struct domain *d, const struct 
> hvm_pirq_dpci *pirq_dpci)
>  
>  ASSERT(pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI);
>  
> -vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
> +if ( hvm_funcs.deliver_posted_intr && pirq_dpci->gmsi.dest_vcpu_id != -1 
> )
> +/*
> + * When using posted interrupts multi-destination delivery mode is
> + * forced to select a specific vCPU so that the PIRR can be synced 
> into
> + * IRR when the interrupt is destroyed or moved.
> + */
> +vmsi_inj_irq(vcpu_vlapic(d->vcpu[pirq_dpci->gmsi.dest_vcpu_id]),
> + vector, trig_mode, delivery_mode);
> +else
> +vmsi_deliver(d, vector, dest, dest_mode, delivery_mode, trig_mode);
>  }
>  
>  /* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index b292e79382..d3f1ae5c39 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -341,7 +341,7 @@ int pt_irq_create_bind(
>  {
>  uint8_t dest, delivery_mode;
>  bool dest_mode;
> -int dest_vcpu_id;
> +int dest_vcpu_id, prev_vcpu_id = -1;
>  const struct vcpu *vcpu;
>  uint32_t gflags = pt_irq_bind->u.msi.gflags &
>~XEN_DOMCTL_VMSI_X86_UNMASKED;
> @@ -411,6 +411,7 @@ int pt_irq_create_bind(
>  
>  pirq_dpci->gmsi.gvec = pt_irq_bind->u.msi.gvec;
>  pirq_dpci->gmsi.gflags = gflags;
> +prev_vcpu_id = pirq_dpci->gmsi.dest_vcpu_id;
>  }
>  }
>  /* Calculate dest_vcpu_id for MSI-type pirq migration. */
> @@ -426,14 +427,24 @@ int pt_irq_create_bind(
>  
>  pirq_dpci->gmsi.posted = false;
>  vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;
> -if ( 

Re: [Xen-devel] [PATCH for-4.13 v2 0/2] x86/ioapic: fix clear_IO_APIC_pin when using interrupt remapping

[Jürgen Groß]

On 10.11.19 10:25, Roger Pau Monne wrote:

Hello,

Current code in clear_IO_APIC_pin doesn't properly deal with IO-APIC
entries already configured to point to entries in the iommu interrupt
remapping table, fix this.

Roger Pau Monne (2):
   x86/ioapic: remove usage of TRUE and FALSE in clear_IO_APIC_pin
   x86/ioapic: fix clear_IO_APIC_pin write of raw entries

  xen/arch/x86/io_apic.c | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)



For the series:

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] x86/ioapic: fix clear_IO_APIC_pin write of raw entries

[Jan Beulich]

On 10.11.2019 10:25, Roger Pau Monne wrote:
> clear_IO_APIC_pin can be called after the iommu has been enabled, and
> using raw reads and writes to modify IO-APIC entries that have been
> setup to use interrupt remapping can lead to issues as some of the
> fields have different meaning when the IO-APIC entry is setup to point
> to an interrupt remapping table entry.
> 
> The following ASSERT in AMD IOMMU code triggers afterwards as a result
> of the raw changes to IO-APIC entries performed by clear_IO_APIC_pin.
> 
> (XEN) [   10.082154] ENABLING IO-APIC IRQs
> (XEN) [   10.087789]  -> Using new ACK method
> (XEN) [   10.093738] Assertion 'get_rte_index(rte) == offset' failed at 
> iommu_intr.c:328
> 
> Fix this by making sure that modifications to entries are performed in
> non raw mode.

... when fields are affected which may either have changed meaning
with interrupt remapping, or which may need mirroring into IRTEs.

> Reported-by: Sergey Dyasli 
> Signed-off-by: Roger Pau Monné 

With the above addition (or something substantially similar)
Reviewed-by: Jan Beulich 
Of course the adjustment is easy enough to do while committing.

Jan

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

[Xen-devel] [xen-4.12-testing test] 143996: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 143190
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 143190
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 143190
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 143190

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail  like 143190
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-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-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail