[Xen-devel] [linux-4.9 test] 125896: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken  in 125869
 build-arm64-pvopsbroken  in 125869
 build-arm64-xsm  broken  in 125869

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 125869
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 125869

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm 2 hosts-allocate broken in 125869 REGR. vs. 125183
 build-arm64-pvops   2 hosts-allocate broken in 125869 REGR. vs. 125183
 build-arm64 2 hosts-allocate broken in 125869 REGR. vs. 125183

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 125869 n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked in 125869 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 125869 n/a
 build-arm64-libvirt   1 build-check(1)   blocked in 125869 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 125869 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 125869 n/a
 build-arm64-xsm  3 capture-logs broken in 125869 blocked in 125183
 build-arm64-pvops3 capture-logs broken in 125869 blocked in 125183
 build-arm64  3 capture-logs broken in 125869 blocked in 125183
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125183
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125183
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125183
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125183
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125183
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemut-ws16-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-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

[Xen-devel] [xen-unstable test] 125892: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   6 xen-installfail pass in 125866

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 125691
 build-arm64   2 hosts-allocate broken REGR. vs. 125691
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125691

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

version targeted for testing:
 xen  ed5f8d9ca47e69e30221c37ec812f2b38af19d83

[Xen-devel] [linux-next test] 125888: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64  broken
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 125848
 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125848
 test-amd64-amd64-xl-shadow   12 guest-start  fail REGR. vs. 125848
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 125848
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 125848
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
125848
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
125848
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 125848
 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 125848
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 125848
 test-amd64-amd64-xl-xsm  12 guest-start  fail REGR. vs. 125848
 test-amd64-amd64-xl  12 guest-start  fail REGR. vs. 125848
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 125848
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
125848
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125848
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125848
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125848
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 125848
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125848
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125848
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 125848
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 125848
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125848
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 125848
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125848
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 125848
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 125848
 test-amd64-amd64-libvirt-xsm 12 guest-start  fail REGR. vs. 125848
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 125848
 test-amd64-amd64-xl-credit2  12 guest-start  fail REGR. vs. 125848
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 125848
 build-i386-pvops  6 kernel-build fail REGR. vs. 125848
 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125848
 test-amd64-amd64-amd64-pvgrub 10 debian-di-install   fail REGR. vs. 125848
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 125848
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 125848

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   

Re: [Xen-devel] [PATCH v3 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR entries

[Tamas K Lengyel]

On Wed, Aug 8, 2018 at 3:54 AM Jan Beulich  wrote:
>
> >>> On 08.08.18 at 10:25,  wrote:
> > On Tue, Aug 07, 2018 at 10:45:32AM -0600, Tamas K Lengyel wrote:
> >> On Tue, Aug 7, 2018 at 10:04 AM Tamas K Lengyel
> >>  wrote:
> >> (XEN) [VT-D]iommu.c:919: iommu_fault_status: Fault Overflow
> >> (XEN) [VT-D]iommu.c:921: iommu_fault_status: Primary Pending Fault
> >> (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
> >> 428f926000, iommu reg = 82c000a0c000
> >> (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
> >> (XEN) print_vtd_entries: iommu #0 dev :00:02.0 gmfn 428f926
> >> (XEN) root_entry[00] = 43aaae001
> >> (XEN) context[10] = 2_43cf92001
> >> (XEN) l4[000] = 9c043cf91107
> >> (XEN) l3[10a] = 8000
> >> (XEN) l3[10a] not present
> >>
> >> The fault is repeated a million times per second and the system is
> >> pretty much stalled.
> >
> > As Jan says, this page is outside of any range in the memory map. I
> > wonder however what's in there.
> >
> > I think (also seeing the PV issues) you should bring this up with the
> > driver maintainers, it might actually be a bug that the driver is
> > trying to access such address.
>
> Right, especially considering that the address does not appear to be
> invariant, I suspect the driver sets up some I/O from (presumably)
> uninitialized data. This goes unnoticed until DMA translation comes
> into play. Tamas - did you try enabling DMA translation in Linux
> when not running on top of Xen? Depending on the
> CONFIG_INTEL_IOMMU_DEFAULT_ON setting this may not be the
> default.

I checked and this kernel option is not enabled. Are you suggesting to
try booting just Linux with this option enabled to see what happens?

>
> > In the meantime, you can try to add to the command line:
> >
> > rmrr=0x428f926=0:0:2.0
> >
> > In order to force an iommu mapping of this address.
>
> I suspect this won't help much.
>

The mfn is not always the same but seems to be at least on some
occasion. I managed to reboot with the right rmrr= option set but I'm
still getting the same faults over and over for that mfn I set in the
rmrr= option.

Tamas

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

Re: [Xen-devel] [OSSTEST PATCH] production-config: Temporarily drop arm64

[Rich Persaud]

On Aug 14, 2018, at 18:46, Julien Grall  wrote:
> 
> Hi Rich,
> 
>> On 08/14/2018 11:42 PM, Rich Persaud wrote:
>>> On Aug 13, 2018, at 10:57, Ian Jackson  wrote:
>>> 
>>> Both our arm64 boxes are out of commission and repairing them is
>>> taking too long.
>> Apologies if this is already documented elsewhere - does OSStest use Qemu 
>> for arm64 testing?
> 
> Osstest does not use QEMU for testing, but I think it would be too slow to 
> have result in timely manner and use x86 resource as well.

To avoid having zero test coverage for one target architecture, it may be 
acceptable to temporarily reduce test capacity for other target architectures.  
QEMU has the advantage of being faster to "rack" a test architecture for 
temporary use.

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

Re: [Xen-devel] [PATCH 03/15] xen/arm: Introduce helpers to clear/flags flags in HCR_EL2

[Stefano Stabellini]

On Tue, 14 Aug 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 08/14/2018 10:49 PM, Stefano Stabellini wrote:
> > On Tue, 14 Aug 2018, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 08/14/2018 09:46 PM, Stefano Stabellini wrote:
> > > > On Mon, 16 Jul 2018, Julien Grall wrote:
> > > > > A couple of places in the code will need to clear/set flags in HCR_EL2
> > > > > for a given vCPU and then replicate into the hardware. Introduce
> > > > > helpers and replace open-coded version.
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > 
> > > > The macros look good, but I grepped for them in your series and there
> > > > are no more callers. What places are you referring to that they will
> > > > need them?
> > > 
> > > I split some of my work in 2 part to reduce the size of the series. This
> > > will
> > > be used in another series where updating HCR for trapping TTBR/SCTLR* will
> > > be
> > > dynamic.
> > > 
> > > Although in general, this is an improvement compare to the current code as
> > > it
> > > makes clear what needs to be updated when modifying HCR.
> > 
> > Yes, it is, but normally I would only introduce vcpu_hcr_set_flags in
> > this series, because vcpu_hcr_clear_flags is left completely unused?
> 
> Well, it makes sense to keep the pair together. I am happy to move that patch
> in the other if you prefer.

Sounds good. When you do that, you can directly add my reviewed-by.

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

Re: [Xen-devel] [PATCH 03/15] xen/arm: Introduce helpers to clear/flags flags in HCR_EL2

[Julien Grall]

Hi Stefano,

On 08/14/2018 10:49 PM, Stefano Stabellini wrote:

On Tue, 14 Aug 2018, Julien Grall wrote:

Hi Stefano,

On 08/14/2018 09:46 PM, Stefano Stabellini wrote:

On Mon, 16 Jul 2018, Julien Grall wrote:

A couple of places in the code will need to clear/set flags in HCR_EL2
for a given vCPU and then replicate into the hardware. Introduce
helpers and replace open-coded version.

Signed-off-by: Julien Grall 


The macros look good, but I grepped for them in your series and there
are no more callers. What places are you referring to that they will
need them?


I split some of my work in 2 part to reduce the size of the series. This will
be used in another series where updating HCR for trapping TTBR/SCTLR* will be
dynamic.

Although in general, this is an improvement compare to the current code as it
makes clear what needs to be updated when modifying HCR.


Yes, it is, but normally I would only introduce vcpu_hcr_set_flags in
this series, because vcpu_hcr_clear_flags is left completely unused?


Well, it makes sense to keep the pair together. I am happy to move that 
patch in the other if you prefer.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 11/15] xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid entry

[Julien Grall]

Hi Stefano,

On 08/14/2018 10:33 PM, Stefano Stabellini wrote:

On Mon, 16 Jul 2018, Julien Grall wrote:

Currently, lpae_is_{table, mapping} helpers will always return false on
entry with the valid bit unset. However, it would be useful to have them

   ^entries


operating on any entry. For instance to store information in advance but
still request a fault.

With that change, the p2m is now providing an overlay for *_is_{table,
mapping} that will check the valid bit of the entry.

Signed-off-by: Julien Grall 

---
  xen/arch/arm/guest_walk.c  |  2 +-
  xen/arch/arm/mm.c  |  2 +-
  xen/arch/arm/p2m.c | 22 ++
  xen/include/asm-arm/lpae.h | 11 +++
  4 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index e3e21bdad3..4a1b4cf2c8 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -566,7 +566,7 @@ static int guest_walk_ld(const struct vcpu *v,
   * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the 
PTE
   * maps a memory block at level 3 (PTE<1:0> == 01).
   */
-if ( !lpae_is_mapping(pte, level) )
+if ( !lpae_is_valid(pte) || !lpae_is_mapping(pte, level) )
  return -EFAULT;
  
  /* Make sure that the lower bits of the PTE's base address are zero. */

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e3dafe5fd7..52e57fef2f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation op,
  for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
  {
  entry = _second[second_linear_offset(addr)];
-if ( !lpae_is_table(*entry, 2) )
+if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
  {
  rc = create_xen_table(entry);
  if ( rc < 0 ) {
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ec3fdcb554..07925a1be4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -219,6 +219,20 @@ static p2m_access_t p2m_mem_access_radix_get(struct 
p2m_domain *p2m, gfn_t gfn)
  return radix_tree_ptr_to_int(ptr);
  }
  
+/*

+ * lpae_is_* helpers don't check whether the valid bit is set in the
+ * PTE. Provide our own overlay to check the valid bit.
+ */
+static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
+{
+return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
+}
+
+static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
+{
+return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
+}


I like the idea, but it would be clearer to me if they were called
lpae_is_valid_mapping and lpae_is_valid_superpage respectively. What do
you think?
 > Also, we might as well move them to lpae.h and use them from mm.c and
guest_walk.c as appropriate?


lpae.h is not suitable because as I said in the commit message each 
page-table (stage-1, stage-2) may have a different view of what "valid" 
means.


At the moment, that view is the same but it is not going to stay long 
like that. Hence the reason of prefixing with p2m_. They are specific to 
the p2m. This is giving us some more liberty in the future while making 
the lpae code a bit more generic.


In guest_walk.c there are only one user, so the introduction of an 
helper is quite limited there.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH] production-config: Temporarily drop arm64

[Julien Grall]

Hi Rich,

On 08/14/2018 11:42 PM, Rich Persaud wrote:

On Aug 13, 2018, at 10:57, Ian Jackson  wrote:


Both our arm64 boxes are out of commission and repairing them is
taking too long.


Apologies if this is already documented elsewhere - does OSStest use Qemu for 
arm64 testing?


Osstest does not use QEMU for testing, but I think it would be too slow 
to have result in timely manner and use x86 resource as well.


We are meant to receive more new arm64 hardware in a bit and also 2 
Thunder-X waiting for a Debian upgraded before they can be thrown into 
production.


Cheers,



Rich



--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH] production-config: Temporarily drop arm64

[Rich Persaud]

On Aug 13, 2018, at 10:57, Ian Jackson  wrote:
> 
> Both our arm64 boxes are out of commission and repairing them is
> taking too long.

Apologies if this is already documented elsewhere - does OSStest use Qemu for 
arm64 testing?

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

Re: [Xen-devel] [PATCH] libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2

[Stefano Stabellini]

On Tue, 14 Aug 2018, Christopher Clark wrote:
> Add zero-padding to #defined ACPI table strings that are copied. 
> Provides sufficient characters to satisfy the length required to
> fully populate the destination and prevent array-bounds warnings.
> 
> Signed-off-by: Christopher Clark 
> ---
> 
> Please add this patch to the backport list for the next minor 4.11
> release.
> 
> Prior to this: gcc 8.2 objects to memcpy past bounds:
> 
> | libxl_arm_acpi.c: In function 'make_acpi_header':
> | libxl_arm_acpi.c:208:5: error: 'memcpy' forming offset [5, 6] is out
> of the bounds [0, 4] [-Werror=array-bounds]
> |  memcpy(h->oem_id, ACPI_OEM_ID, sizeof(h->oem_id));
> |  ^
> | libxl_arm_acpi.c:209:5: error: 'memcpy' forming offset [5, 8] is out
> of the bounds [0, 4] [-Werror=array-bounds]
> |  memcpy(h->oem_table_id, ACPI_OEM_TABLE_ID,
> sizeof(h->oem_table_id));
> |
> ^~~
> | libxl_arm_acpi.c:211:5: error: 'memcpy' forming offset 4 is out of the
> bounds [0, 3] [-Werror=array-bounds]
> |  memcpy(h->asl_compiler_id, ACPI_ASL_COMPILER_ID,
> |  ^~~~
> | sizeof(h->asl_compiler_id));
> | ~~~
> | In function 'make_acpi_rsdp.isra.4',
> | inlined from 'libxl__prepare_acpi' at libxl_arm_acpi.c:389:5:
> | libxl_arm_acpi.c:193:5: error: 'memcpy' forming offset [5, 6] is out
> of the bounds [0, 4] [-Werror=array-bounds]
> |  memcpy(rsdp->oem_id, ACPI_OEM_ID, sizeof(rsdp->oem_id));
> |  ^~~
> 
>  tools/libxl/libxl_arm_acpi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 636f724..eeca1de 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -48,9 +48,9 @@ extern const unsigned char dsdt_anycpu_arm[];
>  _hidden
>  extern const int dsdt_anycpu_arm_len;
>  
> -#define ACPI_OEM_ID "Xen"
> -#define ACPI_OEM_TABLE_ID "ARM"
> -#define ACPI_ASL_COMPILER_ID "XL"
> +#define ACPI_OEM_ID "Xen\0\0"
> +#define ACPI_OEM_TABLE_ID "ARM\0\0\0\0"
> +#define ACPI_ASL_COMPILER_ID "XL\0"
>  
>  enum {
>  RSDP,

Thank you for the patch! These changes should fix the errors.
Alternatively, changing the three memcpy's in the following way would
also work:

  memcpy(rsdp->oem_id, ACPI_OEM_ID, sizeof(ACPI_OEM_ID));

I don't have an opinion on which way is best so:

Reviewed-by: Stefano Stabellini 

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

[Xen-devel] [PATCH] libxl: start pvqemu when 9pfs is requested

[Stefano Stabellini]

PV 9pfs requires the PV backend in QEMU. Make sure that libxl knows it.

Signed-off-by: Stefano Stabellini 
---

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fdd7fa3..70e8b16 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2598,7 +2598,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, 
libxl_domain_config *d_config)
 goto out;
 }
 
-if (d_config->num_vfbs > 0) {
+if (d_config->num_vfbs > 0 || d_config->num_p9s > 0) {
 ret = 1;
 goto out;
 }

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

Re: [Xen-devel] [PATCH 03/15] xen/arm: Introduce helpers to clear/flags flags in HCR_EL2

[Stefano Stabellini]

On Tue, 14 Aug 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 08/14/2018 09:46 PM, Stefano Stabellini wrote:
> > On Mon, 16 Jul 2018, Julien Grall wrote:
> > > A couple of places in the code will need to clear/set flags in HCR_EL2
> > > for a given vCPU and then replicate into the hardware. Introduce
> > > helpers and replace open-coded version.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > The macros look good, but I grepped for them in your series and there
> > are no more callers. What places are you referring to that they will
> > need them?
> 
> I split some of my work in 2 part to reduce the size of the series. This will
> be used in another series where updating HCR for trapping TTBR/SCTLR* will be
> dynamic.
> 
> Although in general, this is an improvement compare to the current code as it
> makes clear what needs to be updated when modifying HCR.

Yes, it is, but normally I would only introduce vcpu_hcr_set_flags in
this series, because vcpu_hcr_clear_flags is left completely unused?

I also don't mind introducing it anyway if you have a series coming.

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

Re: [Xen-devel] [PATCH 01/15] xen/arm: cpregs: Allow HSR_CPREG* to receive more than 1 parameter

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> At the moment, HSR_CPREG is expected to receive only the co-processor
> register name in parameter. Because the name is actually a define, this
> may have been expanded by a previous macro.
> 
> Rather than imposing the use of _HSR_CPREG* in such cases, allow
> HSR_CPREG to receive more than 1 parameter.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/include/asm-arm/cpregs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index 8db65d5e2a..4c74e8161b 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -47,8 +47,8 @@
>  ((__HSR_CPREG_##op1) << HSR_CP64_OP1_SHIFT)
>  
>  /* Encode a register as per HSR ISS pattern */
> -#define HSR_CPREG32(X) _HSR_CPREG32(X)
> -#define HSR_CPREG64(X) _HSR_CPREG64(X)
> +#define HSR_CPREG32(X...) _HSR_CPREG32(X)
> +#define HSR_CPREG64(X...) _HSR_CPREG64(X)
>  
>  /*
>   * Order registers by Coprocessor-> CRn-> Opcode 1-> CRm-> Opcode 2
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 15/15] xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> GUEST_BUG_ON may be used in other files doing guest emulation.
> 
> Signed-off-by: Julien Grall 

Given that GUEST_BUG_ON is not actually used in any other files in this
patch series, I assume you are referring to one of your future series?


> ---
>  xen/arch/arm/traps.c| 24 
>  xen/include/asm-arm/traps.h | 24 
>  2 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index d1bf69b245..6751e4d754 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -68,30 +68,6 @@ static inline void check_stack_alignment_constraints(void) 
> {
>  #endif
>  }
>  
> -/*
> - * GUEST_BUG_ON is intended for checking that the guest state has not been
> - * corrupted in hardware and/or that the hardware behaves as we
> - * believe it should (i.e. that certain traps can only occur when the
> - * guest is in a particular mode).
> - *
> - * The intention is to limit the damage such h/w bugs (or spec
> - * misunderstandings) can do by turning them into Denial of Service
> - * attacks instead of e.g. information leaks or privilege escalations.
> - *
> - * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
> - *
> - * Compared with regular BUG_ON it dumps the guest vcpu state instead
> - * of Xen's state.
> - */
> -#define guest_bug_on_failed(p)  \
> -do {\
> -show_execution_state(guest_cpu_user_regs());\
> -panic("Guest Bug: %pv: '%s', line %d, file %s\n",   \
> -  current, p, __LINE__, __FILE__);  \
> -} while (0)
> -#define GUEST_BUG_ON(p) \
> -do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
> -
>  #ifdef CONFIG_ARM_32
>  static int debug_stack_lines = 20;
>  #define stack_words_per_line 8
> diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
> index 70b52d1d16..0acf7de67d 100644
> --- a/xen/include/asm-arm/traps.h
> +++ b/xen/include/asm-arm/traps.h
> @@ -9,6 +9,30 @@
>  # include 
>  #endif
>  
> +/*
> + * GUEST_BUG_ON is intended for checking that the guest state has not been
> + * corrupted in hardware and/or that the hardware behaves as we
> + * believe it should (i.e. that certain traps can only occur when the
> + * guest is in a particular mode).
> + *
> + * The intention is to limit the damage such h/w bugs (or spec
> + * misunderstandings) can do by turning them into Denial of Service
> + * attacks instead of e.g. information leaks or privilege escalations.
> + *
> + * GUEST_BUG_ON *MUST* *NOT* be used to check for guest controllable state!
> + *
> + * Compared with regular BUG_ON it dumps the guest vcpu state instead
> + * of Xen's state.
> + */
> +#define guest_bug_on_failed(p)  \
> +do {\
> +show_execution_state(guest_cpu_user_regs());\
> +panic("Guest Bug: %pv: '%s', line %d, file %s\n",   \
> +  current, p, __LINE__, __FILE__);  \
> +} while (0)
> +#define GUEST_BUG_ON(p) \
> +do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
> +
>  int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr);
>  
>  void advance_pc(struct cpu_user_regs *regs, const union hsr hsr);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 14/15] xen/arm: guest_walk_tables: Switch the return to bool

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> At the moment, guest_walk_tables can either return 0, -EFAULT, -EINVAL.
> The use of the last 2 are not clearly defined and used inconsistently in
> the code. The current only caller does not care about the return
> value and the value of it seems very limited (no way to differentiate
> between the 15ish error paths).
> 
> So switch to bool to simplify the return and make the developper life a
   ^ developer


> bit easier.
> 
> Signed-off-by: Julien Grall 

Aside from the minor typo:

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/guest_walk.c| 50 
> 
>  xen/arch/arm/mem_access.c|  2 +-
>  xen/include/asm-arm/guest_walk.h |  8 +++
>  3 files changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index 4a1b4cf2c8..7db7a7321b 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -28,9 +28,9 @@
>   * page table on a different vCPU, the following registers would need to be
>   * loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and SCTLR_EL1.
>   */
> -static int guest_walk_sd(const struct vcpu *v,
> - vaddr_t gva, paddr_t *ipa,
> - unsigned int *perms)
> +static bool guest_walk_sd(const struct vcpu *v,
> +  vaddr_t gva, paddr_t *ipa,
> +  unsigned int *perms)
>  {
>  int ret;
>  bool disabled = true;
> @@ -79,7 +79,7 @@ static int guest_walk_sd(const struct vcpu *v,
>  }
>  
>  if ( disabled )
> -return -EFAULT;
> +return false;
>  
>  /*
>   * The address of the L1 descriptor for the initial lookup has the
> @@ -97,12 +97,12 @@ static int guest_walk_sd(const struct vcpu *v,
>  /* Access the guest's memory to read only one PTE. */
>  ret = access_guest_memory_by_ipa(d, paddr, , sizeof(short_desc_t), 
> false);
>  if ( ret )
> -return -EINVAL;
> +return false;
>  
>  switch ( pte.walk.dt )
>  {
>  case L1DESC_INVALID:
> -return -EFAULT;
> +return false;
>  
>  case L1DESC_PAGE_TABLE:
>  /*
> @@ -122,10 +122,10 @@ static int guest_walk_sd(const struct vcpu *v,
>  /* Access the guest's memory to read only one PTE. */
>  ret = access_guest_memory_by_ipa(d, paddr, , 
> sizeof(short_desc_t), false);
>  if ( ret )
> -return -EINVAL;
> +return false;
>  
>  if ( pte.walk.dt == L2DESC_INVALID )
> -return -EFAULT;
> +return false;
>  
>  if ( pte.pg.page ) /* Small page. */
>  {
> @@ -175,7 +175,7 @@ static int guest_walk_sd(const struct vcpu *v,
>  *perms |= GV2M_EXEC;
>  }
>  
> -return 0;
> +return true;
>  }
>  
>  /*
> @@ -355,9 +355,9 @@ static bool check_base_size(unsigned int output_size, 
> uint64_t base)
>   * page table on a different vCPU, the following registers would need to be
>   * loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and SCTLR_EL1.
>   */
> -static int guest_walk_ld(const struct vcpu *v,
> - vaddr_t gva, paddr_t *ipa,
> - unsigned int *perms)
> +static bool guest_walk_ld(const struct vcpu *v,
> +  vaddr_t gva, paddr_t *ipa,
> +  unsigned int *perms)
>  {
>  int ret;
>  bool disabled = true;
> @@ -442,7 +442,7 @@ static int guest_walk_ld(const struct vcpu *v,
>   */
>  if ( (input_size > TCR_EL1_IPS_48_BIT_VAL) ||
>   (input_size < TCR_EL1_IPS_MIN_VAL) )
> -return -EFAULT;
> +return false;
>  }
>  else
>  {
> @@ -487,7 +487,7 @@ static int guest_walk_ld(const struct vcpu *v,
>  }
>  
>  if ( disabled )
> -return -EFAULT;
> +return false;
>  
>  /*
>   * The starting level is the number of strides (grainsizes[gran] - 3)
> @@ -498,12 +498,12 @@ static int guest_walk_ld(const struct vcpu *v,
>  /* Get the IPA output_size. */
>  ret = get_ipa_output_size(d, tcr, _size);
>  if ( ret )
> -return -EFAULT;
> +return false;
>  
>  /* Make sure the base address does not exceed its configured size. */
>  ret = check_base_size(output_size, ttbr);
>  if ( !ret )
> -return -EFAULT;
> +return false;
>  
>  /*
>   * Compute the base address of the first level translation table that is
> @@ -523,12 +523,12 @@ static int guest_walk_ld(const struct vcpu *v,
>  /* Access the guest's memory to read only one PTE. */
>  ret = access_guest_memory_by_ipa(d, paddr, , sizeof(lpae_t), 
> false);
>  if ( ret )
> -return -EFAULT;
> +return false;
>  
>  /* Make sure the base address does not exceed its configured size. */
>  ret = 

Re: [Xen-devel] [PATCH 13/15] xen/arm: p2m: Introduce a new variable removing_mapping in __p2m_set_entry

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> This is making the code slightly easier to understand.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/p2m.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 66d58fabd7..e826f57842 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -792,6 +792,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  unsigned int target = 3 - (page_order / LPAE_SHIFT);
>  lpae_t *entry, *table, orig_pte;
>  int rc;
> +/* A mapping is removed if the MFN is invalid. */
> +bool removing_mapping = mfn_eq(smfn, INVALID_MFN);
>  
>  /* Convenience aliases */
>  const unsigned int offsets[4] = {
> @@ -817,9 +819,9 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  {
>  /*
>   * Don't try to allocate intermediate page table if the mapping
> - * is about to be removed (i.e mfn == INVALID_MFN).
> + * is about to be removed.
>   */
> -rc = p2m_next_level(p2m, mfn_eq(smfn, INVALID_MFN),
> +rc = p2m_next_level(p2m, removing_mapping,
>  level, , offsets[level]);
>  if ( rc == GUEST_TABLE_MAP_FAILED )
>  {
> @@ -830,7 +832,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>   * when removing a mapping as it may not exist in the
>   * page table. In this case, just ignore it.
>   */
> -rc = mfn_eq(smfn, INVALID_MFN) ? 0 : -ENOENT;
> +rc = removing_mapping ?  0 : -ENOENT;
>  goto out;
>  }
>  else if ( rc != GUEST_TABLE_NORMAL_PAGE )
> @@ -925,7 +927,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  if ( lpae_is_valid(orig_pte) )
>  p2m_remove_pte(entry, p2m->clean_pte);
>  
> -if ( mfn_eq(smfn, INVALID_MFN) )
> +if ( removing_mapping )
>  /* Flush can be deferred if the entry is removed */
>  p2m->need_flush |= !!lpae_is_valid(orig_pte);
>  else
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 12/15] xen/arm: p2m: Rename ret to mfn in p2m_lookup

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Comestic change to make clearer what is the return ('ret' is a bit
> too generic).
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 

> ---
>  xen/arch/arm/p2m.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 07925a1be4..66d58fabd7 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -383,14 +383,14 @@ out:
>  
>  mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
>  {
> -mfn_t ret;
> +mfn_t mfn;
>  struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  
>  p2m_read_lock(p2m);
> -ret = p2m_get_entry(p2m, gfn, t, NULL, NULL);
> +mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);
>  p2m_read_unlock(p2m);
>  
> -return ret;
> +return mfn;
>  }
>  
>  int guest_physmap_mark_populate_on_demand(struct domain *d,
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 11/15] xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid entry

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Currently, lpae_is_{table, mapping} helpers will always return false on
> entry with the valid bit unset. However, it would be useful to have them
  ^entries

> operating on any entry. For instance to store information in advance but
> still request a fault.
> 
> With that change, the p2m is now providing an overlay for *_is_{table,
> mapping} that will check the valid bit of the entry.
> 
> Signed-off-by: Julien Grall 
>
> ---
>  xen/arch/arm/guest_walk.c  |  2 +-
>  xen/arch/arm/mm.c  |  2 +-
>  xen/arch/arm/p2m.c | 22 ++
>  xen/include/asm-arm/lpae.h | 11 +++
>  4 files changed, 27 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index e3e21bdad3..4a1b4cf2c8 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -566,7 +566,7 @@ static int guest_walk_ld(const struct vcpu *v,
>   * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the 
> PTE
>   * maps a memory block at level 3 (PTE<1:0> == 01).
>   */
> -if ( !lpae_is_mapping(pte, level) )
> +if ( !lpae_is_valid(pte) || !lpae_is_mapping(pte, level) )
>  return -EFAULT;
>  
>  /* Make sure that the lower bits of the PTE's base address are zero. */
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index e3dafe5fd7..52e57fef2f 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
>  {
>  entry = _second[second_linear_offset(addr)];
> -if ( !lpae_is_table(*entry, 2) )
> +if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
>  {
>  rc = create_xen_table(entry);
>  if ( rc < 0 ) {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ec3fdcb554..07925a1be4 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -219,6 +219,20 @@ static p2m_access_t p2m_mem_access_radix_get(struct 
> p2m_domain *p2m, gfn_t gfn)
>  return radix_tree_ptr_to_int(ptr);
>  }
>  
> +/*
> + * lpae_is_* helpers don't check whether the valid bit is set in the
> + * PTE. Provide our own overlay to check the valid bit.
> + */
> +static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
> +{
> +return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
> +}
> +
> +static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
> +{
> +return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
> +}

I like the idea, but it would be clearer to me if they were called
lpae_is_valid_mapping and lpae_is_valid_superpage respectively. What do
you think?

Also, we might as well move them to lpae.h and use them from mm.c and
guest_walk.c as appropriate?


>  #define GUEST_TABLE_MAP_FAILED 0
>  #define GUEST_TABLE_SUPER_PAGE 1
>  #define GUEST_TABLE_NORMAL_PAGE 2
> @@ -262,7 +276,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  
>  /* The function p2m_next_level is never called at the 3rd level */
>  ASSERT(level < 3);
> -if ( lpae_is_mapping(*entry, level) )
> +if ( p2m_is_mapping(*entry, level) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
>  mfn = lpae_to_mfn(*entry);
> @@ -642,7 +656,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  return;
>  
>  /* Nothing to do but updating the stats if the entry is a super-page. */
> -if ( lpae_is_superpage(entry, level) )
> +if ( p2m_is_superpage(entry, level) )
>  {
>  p2m->stats.mappings[level]--;
>  return;
> @@ -697,7 +711,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>   * a superpage.
>   */
>  ASSERT(level < target);
> -ASSERT(lpae_is_superpage(*entry, level));
> +ASSERT(p2m_is_superpage(*entry, level));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( !page )
> @@ -834,7 +848,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  /* We need to split the original page. */
>  lpae_t split_pte = *entry;
>  
> -ASSERT(lpae_is_superpage(*entry, level));
> +ASSERT(p2m_is_superpage(*entry, level));
>  
>  if ( !p2m_split_superpage(p2m, _pte, level, target, offsets) )
>  {
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index 05c87a8f48..88f30fc917 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -133,16 +133,19 @@ static inline bool lpae_is_valid(lpae_t pte)
>  return pte.walk.valid;
>  }
>  
> +/*
> + * lpae_is_* don't check the valid bit. This gives an opportunity for the
> + * callers to operate on the entry even if they are not valid. For
> + * instance to store information in advance.
> + */
>  static inline bool lpae_is_table(lpae_t pte, unsigned int level)
>  {
> -return (level < 3) && 

Re: [Xen-devel] [PATCH 10/15] xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> The new helpers make easier to read the code by abstracting the way to
  ^ it

> set/get an MFN from/to an LPAE entry. The helpers is using "walk" as the
^are

> bits are common for accross different LPAE stage.
  ^ across   ^ stages


> At the same time, use the new helpers to replace the various open-coding
> place.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c  | 10 +-
>  xen/arch/arm/p2m.c | 19 ++-
>  xen/include/asm-arm/lpae.h |  3 +++
>  3 files changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index de9b965d2f..e3dafe5fd7 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -238,7 +238,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
>  
>  /* For next iteration */
>  unmap_domain_page(mapping);
> -mapping = map_domain_page(_mfn(pte.walk.base));
> +mapping = map_domain_page(lpae_to_mfn(pte));
>  }
>  
>  unmap_domain_page(mapping);
> @@ -323,7 +323,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
> attr)
>  
>  ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
>  
> -e.pt.base = mfn_x(mfn);
> +lpae_set_mfn(e, mfn);
>  
>  return e;
>  }
> @@ -490,7 +490,7 @@ mfn_t domain_page_map_to_mfn(const void *ptr)
>  ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
>  ASSERT(map[slot].pt.avail != 0);
>  
> -return _mfn(map[slot].pt.base + offset);
> +return mfn_add(lpae_to_mfn(map[slot]), offset);
>  }
>  #endif
>  
> @@ -851,7 +851,7 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
>  /* mfn_to_virt is not valid on the 1st 1st mfn, since it
>   * is not within the xenheap. */
>  first = slot == xenheap_first_first_slot ?
> -xenheap_first_first : __mfn_to_virt(p->pt.base);
> +xenheap_first_first : mfn_to_virt(lpae_to_mfn(*p));
>  }
>  else if ( xenheap_first_first_slot == -1)
>  {
> @@ -1007,7 +1007,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  
>  BUG_ON(!lpae_is_valid(*entry));
>  
> -third = __mfn_to_virt(entry->pt.base);
> +third = mfn_to_virt(lpae_to_mfn(*entry));
>  entry = [third_table_offset(addr)];
>  
>  switch ( op ) {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index a80ac301c5..ec3fdcb554 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -265,7 +265,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  if ( lpae_is_mapping(*entry, level) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
> -mfn = _mfn(entry->p2m.base);
> +mfn = lpae_to_mfn(*entry);
>  
>  unmap_domain_page(*table);
>  *table = map_domain_page(mfn);
> @@ -349,7 +349,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  if ( a )
>  *a = p2m_mem_access_radix_get(p2m, gfn);
>  
> -mfn = _mfn(entry.p2m.base);
> +mfn = lpae_to_mfn(entry);
>  /*
>   * The entry may point to a superpage. Find the MFN associated
>   * to the GFN.
> @@ -519,7 +519,7 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
> p2m_access_t a)
>  
>  ASSERT(!(mfn_to_maddr(mfn) & ~PADDR_MASK));
>  
> -e.p2m.base = mfn_x(mfn);
> +lpae_set_mfn(e, mfn);
>  
>  return e;
>  }
> @@ -621,7 +621,7 @@ static void p2m_put_l3_page(const lpae_t pte)
>   */
>  if ( p2m_is_foreign(pte.p2m.type) )
>  {
> -mfn_t mfn = _mfn(pte.p2m.base);
> +mfn_t mfn = lpae_to_mfn(pte);
>  
>  ASSERT(mfn_valid(mfn));
>  put_page(mfn_to_page(mfn));
> @@ -655,7 +655,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  return;
>  }
>  
> -table = map_domain_page(_mfn(entry.p2m.base));
> +table = map_domain_page(lpae_to_mfn(entry));
>  for ( i = 0; i < LPAE_ENTRIES; i++ )
>  p2m_free_entry(p2m, *(table + i), level + 1);
>  
> @@ -669,7 +669,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>   */
>  p2m_tlb_flush_sync(p2m);
>  
> -mfn = _mfn(entry.p2m.base);
> +mfn = lpae_to_mfn(entry);
>  ASSERT(mfn_valid(mfn));
>  
>  pg = mfn_to_page(mfn);
> @@ -688,7 +688,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>  bool rv = true;
>  
>  /* Convenience aliases */
> -mfn_t mfn = _mfn(entry->p2m.base);
> +mfn_t mfn = lpae_to_mfn(*entry);
>  unsigned int next_level = level + 1;
>  unsigned int level_order = level_orders[next_level];
>  
> @@ -719,7 +719,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>   * the necessary fields. So the correct permission are kept.
>   */
>  pte = *entry;
> -pte.p2m.base = mfn_x(mfn_add(mfn, i << 

Re: [Xen-devel] [PATCH 03/15] xen/arm: Introduce helpers to clear/flags flags in HCR_EL2

[Julien Grall]

Hi Stefano,

On 08/14/2018 09:46 PM, Stefano Stabellini wrote:

On Mon, 16 Jul 2018, Julien Grall wrote:

A couple of places in the code will need to clear/set flags in HCR_EL2
for a given vCPU and then replicate into the hardware. Introduce
helpers and replace open-coded version.

Signed-off-by: Julien Grall 


The macros look good, but I grepped for them in your series and there
are no more callers. What places are you referring to that they will
need them?


I split some of my work in 2 part to reduce the size of the series. This 
will be used in another series where updating HCR for trapping 
TTBR/SCTLR* will be dynamic.


Although in general, this is an improvement compare to the current code 
as it makes clear what needs to be updated when modifying HCR.


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  aa67b97ed34279c43a43d9ca46727b5746caa92e
baseline version:
 xen  2a3b34ec47817048ab59586855cf0709fc77487e

Last test of basis   125897  2018-08-13 17:00:28 Z1 days
Testing same since   125910  2018-08-14 18:00:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2a3b34ec47..aa67b97ed3  aa67b97ed34279c43a43d9ca46727b5746caa92e -> smoke

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

Re: [Xen-devel] [PATCH 09/15] xen/arm: guest_walk: Use lpae_is_mapping to simplify the code

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> !lpae_is_page(pte, level) && !lpae_is_superpage(pte, level) is
> equivalent to !lpae_is_mapping(pte, level).
> 
> At the same time drop lpae_is_page(pte, level) that is now unused.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/guest_walk.c  | 2 +-
>  xen/include/asm-arm/lpae.h | 5 -
>  2 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index a7c7e05603..e3e21bdad3 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -566,7 +566,7 @@ static int guest_walk_ld(const struct vcpu *v,
>   * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the 
> PTE
>   * maps a memory block at level 3 (PTE<1:0> == 01).
>   */
> -if ( !lpae_is_page(pte, level) && !lpae_is_superpage(pte, level) )
> +if ( !lpae_is_mapping(pte, level) )
>  return -EFAULT;
>  
>  /* Make sure that the lower bits of the PTE's base address are zero. */
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index 1d86020d07..15595cd35c 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -153,11 +153,6 @@ static inline bool lpae_is_superpage(lpae_t pte, 
> unsigned int level)
>  return (level < 3) && lpae_is_mapping(pte, level);
>  }
>  
> -static inline bool lpae_is_page(lpae_t pte, unsigned int level)
> -{
> -return (level == 3) && lpae_is_valid(pte) && pte.walk.table;
> -}
> -
>  /*
>   * AArch64 supports pages with different sizes (4K, 16K, and 64K). To enable
>   * page table walks for various configurations, the following helpers enable
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 08/15] xen/arm: Rename lpae_valid to lpae_is_valid

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> This will help to keep the naming consistent accross all lpae helpers.
> 
> No functional change intended.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/guest_walk.c  |  2 +-
>  xen/arch/arm/mm.c  |  6 +++---
>  xen/arch/arm/p2m.c | 20 ++--
>  xen/include/asm-arm/lpae.h |  8 
>  4 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index 4d1ea0cdc1..a7c7e05603 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -546,7 +546,7 @@ static int guest_walk_ld(const struct vcpu *v,
>   * - The PTE is not valid.
>   * - If (level < 3) and the PTE is valid, we found a block 
> descriptor.
>   */
> -if ( level == 3 || !lpae_valid(pte) || lpae_is_superpage(pte, level) 
> )
> +if ( level == 3 || !lpae_is_valid(pte) || lpae_is_superpage(pte, 
> level) )
>  break;
>  
>  /*
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index b7f2dabd05..de9b965d2f 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1005,7 +1005,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  }
>  }
>  
> -BUG_ON(!lpae_valid(*entry));
> +BUG_ON(!lpae_is_valid(*entry));
>  
>  third = __mfn_to_virt(entry->pt.base);
>  entry = [third_table_offset(addr)];
> @@ -1013,7 +1013,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  switch ( op ) {
>  case INSERT:
>  case RESERVE:
> -if ( lpae_valid(*entry) )
> +if ( lpae_is_valid(*entry) )
>  {
>  printk("%s: trying to replace an existing mapping 
> addr=%lx mfn=%"PRI_mfn"\n",
> __func__, addr, mfn_x(mfn));
> @@ -1030,7 +1030,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  break;
>  case MODIFY:
>  case REMOVE:
> -if ( !lpae_valid(*entry) )
> +if ( !lpae_is_valid(*entry) )
>  {
>  printk("%s: trying to %s a non-existing mapping 
> addr=%lx\n",
> __func__, op == REMOVE ? "remove" : "modify", 
> addr);
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 72a84a33fd..a80ac301c5 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -250,7 +250,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  
>  entry = *table + offset;
>  
> -if ( !lpae_valid(*entry) )
> +if ( !lpae_is_valid(*entry) )
>  {
>  if ( read_only )
>  return GUEST_TABLE_MAP_FAILED;
> @@ -342,7 +342,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  
>  entry = table[offsets[level]];
>  
> -if ( lpae_valid(entry) )
> +if ( lpae_is_valid(entry) )
>  {
>  *t = entry.p2m.type;
>  
> @@ -546,7 +546,7 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry)
>  lpae_t *p;
>  lpae_t pte;
>  
> -ASSERT(!lpae_valid(*entry));
> +ASSERT(!lpae_is_valid(*entry));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( page == NULL )
> @@ -610,7 +610,7 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
> *p2m, gfn_t gfn,
>   */
>  static void p2m_put_l3_page(const lpae_t pte)
>  {
> -ASSERT(lpae_valid(pte));
> +ASSERT(lpae_is_valid(pte));
>  
>  /*
>   * TODO: Handle other p2m types
> @@ -638,7 +638,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  struct page_info *pg;
>  
>  /* Nothing to do if the entry is invalid. */
> -if ( !lpae_valid(entry) )
> +if ( !lpae_is_valid(entry) )
>  return;
>  
>  /* Nothing to do but updating the stats if the entry is a super-page. */
> @@ -908,12 +908,12 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>   * sequence when updating the translation table (D4.7.1 in ARM DDI
>   * 0487A.j).
>   */
> -if ( lpae_valid(orig_pte) )
> +if ( lpae_is_valid(orig_pte) )
>  p2m_remove_pte(entry, p2m->clean_pte);
>  
>  if ( mfn_eq(smfn, INVALID_MFN) )
>  /* Flush can be deferred if the entry is removed */
> -p2m->need_flush |= !!lpae_valid(orig_pte);
> +p2m->need_flush |= !!lpae_is_valid(orig_pte);
>  else
>  {
>  lpae_t pte = mfn_to_p2m_entry(smfn, t, a);
> @@ -928,7 +928,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>   * Although, it could be defered when only the permissions are
>   * changed (e.g in case of memaccess).
>   */
> -if ( lpae_valid(orig_pte) )
> +if ( lpae_is_valid(orig_pte) )
>  {
>  if ( likely(!p2m->mem_access_enabled) ||
>   P2M_CLEAR_PERM(pte) != P2M_CLEAR_PERM(orig_pte) )
> @@ -950,11 +950,11 @@ 

Re: [Xen-devel] [PATCH 07/15] xen/arm: Rework lpae_table

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Currently, lpae_table can only work on entry from any level other than
> 3. Make it work with any level by extending the prototype to pass the
> level.
> 
> At the same time, rename the function to lpae_is_mapping so naming stay
> consistent accross all lpae_* helpers.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/mm.c  | 2 +-
>  xen/include/asm-arm/lpae.h | 9 ++---
>  2 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index d234c46e41..b7f2dabd05 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
>  {
>  entry = _second[second_linear_offset(addr)];
> -if ( !lpae_table(*entry) )
> +if ( !lpae_is_table(*entry, 2) )
>  {
>  rc = create_xen_table(entry);
>  if ( rc < 0 ) {
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index 4cf188ff82..c803569c2d 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -133,14 +133,9 @@ static inline bool lpae_valid(lpae_t pte)
>  return pte.walk.valid;
>  }
>  
> -/*
> - * This one can only be used on L0..L2 ptes because L3 mappings set
> - * the table bit and therefore these would return the opposite to what
> - * you would expect.
> - */
> -static inline bool lpae_table(lpae_t pte)
> +static inline bool lpae_is_table(lpae_t pte, unsigned int level)
>  {
> -return lpae_valid(pte) && pte.walk.table;
> +return (level < 3) && lpae_valid(pte) && pte.walk.table;
>  }
>  
>  static inline bool lpae_is_mapping(lpae_t pte, unsigned int level)

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

Re: [Xen-devel] [PATCH 06/15] xen/arm: Rework lpae_mapping

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Currently, lpae_mapping can only work on entry from any level other than
> 3. Make it work with any level by extending the prototype to pass the
> level.
> 
> At the same time, rename the function to lpae_is_mapping so naming stay
> consistent accross lpae_* helpers.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/p2m.c | 12 +++-
>  xen/include/asm-arm/lpae.h | 13 +
>  2 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ebf74760fa..72a84a33fd 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -241,7 +241,8 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry);
>   *  GUEST_TABLE_SUPER_PAGE: The next entry points to a superpage.
>   */
>  static int p2m_next_level(struct p2m_domain *p2m, bool read_only,
> -  lpae_t **table, unsigned int offset)
> +  unsigned int level, lpae_t **table,
> +  unsigned int offset)
>  {
>  lpae_t *entry;
>  int ret;
> @@ -260,7 +261,8 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  }
>  
>  /* The function p2m_next_level is never called at the 3rd level */
> -if ( lpae_mapping(*entry) )
> +ASSERT(level < 3);
> +if ( lpae_is_mapping(*entry, level) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
>  mfn = _mfn(entry->p2m.base);
> @@ -331,7 +333,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  
>  for ( level = P2M_ROOT_LEVEL; level < 3; level++ )
>  {
> -rc = p2m_next_level(p2m, true, , offsets[level]);
> +rc = p2m_next_level(p2m, true, level, , offsets[level]);
>  if ( rc == GUEST_TABLE_MAP_FAILED )
>  goto out_unmap;
>  else if ( rc != GUEST_TABLE_NORMAL_PAGE )
> @@ -804,7 +806,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>   * is about to be removed (i.e mfn == INVALID_MFN).
>   */
>  rc = p2m_next_level(p2m, mfn_eq(smfn, INVALID_MFN),
> -, offsets[level]);
> +level, , offsets[level]);
>  if ( rc == GUEST_TABLE_MAP_FAILED )
>  {
>  /*
> @@ -861,7 +863,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  /* then move to the level we want to make real changes */
>  for ( ; level < target; level++ )
>  {
> -rc = p2m_next_level(p2m, true, , offsets[level]);
> +rc = p2m_next_level(p2m, true, level, , offsets[level]);
>  
>  /*
>   * The entry should be found and either be a table
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index b30853e79d..4cf188ff82 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -134,7 +134,7 @@ static inline bool lpae_valid(lpae_t pte)
>  }
>  
>  /*
> - * These two can only be used on L0..L2 ptes because L3 mappings set
> + * This one can only be used on L0..L2 ptes because L3 mappings set
>   * the table bit and therefore these would return the opposite to what
>   * you would expect.
>   */
> @@ -143,14 +143,19 @@ static inline bool lpae_table(lpae_t pte)
>  return lpae_valid(pte) && pte.walk.table;
>  }
>  
> -static inline bool lpae_mapping(lpae_t pte)
> +static inline bool lpae_is_mapping(lpae_t pte, unsigned int level)
>  {
> -return lpae_valid(pte) && !pte.walk.table;
> +if ( !lpae_valid(pte) )
> +return false;
> +else if ( level == 3 )
> +return pte.walk.table;
> +else
> +return !pte.walk.table;
>  }
>  
>  static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
>  {
> -return (level < 3) && lpae_mapping(pte);
> +return (level < 3) && lpae_is_mapping(pte, level);
>  }
>  
>  static inline bool lpae_is_page(lpae_t pte, unsigned int level)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 05/15] xen/arm: p2m: Limit call to mem access code use in get_page_from_gva

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Mem access has only an impact on the hardware translation between a
> guest virtual address and the machine physical address. So it is not
> necessary to fallback to memaccess for all the other case (e.g when it
> is not possible to acquire the page behind the MFN).
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> ---
>  xen/arch/arm/p2m.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 5ca7ffe41b..ebf74760fa 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1425,17 +1425,24 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  
>  if ( par )
>  {
> +/*
> + * When memaccess is enabled, the translation GVA to MADDR may
> + * have failed because of a permission fault.
> + */
> +if ( p2m->mem_access_enabled )
> +return p2m_mem_access_check_and_get_page(va, flags, v);
> +
>  dprintk(XENLOG_G_DEBUG,
>  "%pv: gvirt_to_maddr failed va=%#"PRIvaddr" flags=0x%lx 
> par=%#"PRIx64"\n",
>  v, va, flags, par);
> -goto err;
> +return NULL;
>  }
>  
>  if ( !mfn_valid(maddr_to_mfn(maddr)) )
>  {
>  dprintk(XENLOG_G_DEBUG, "%pv: Invalid MFN %#"PRI_mfn"\n",
>  v, mfn_x(maddr_to_mfn(maddr)));
> -goto err;
> +return NULL;
>  }
>  
>  page = mfn_to_page(maddr_to_mfn(maddr));
> @@ -1445,13 +1452,9 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  {
>  dprintk(XENLOG_G_DEBUG, "%pv: Failing to acquire the MFN 
> %#"PRI_mfn"\n",
>  v, mfn_x(maddr_to_mfn(maddr)));
> -page = NULL;
> +return NULL;
>  }
>  
> -err:
> -if ( !page && p2m->mem_access_enabled )
> -page = p2m_mem_access_check_and_get_page(va, flags, v);
> -
>  return page;
>  }
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 04/15] xen/arm: p2m: Reduce the locking section in get_page_from_gva

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> The p2m lock is only necessary to prevent gvirt_to_maddr failing when
> break-before-make sequence is used in the P2M update concurrently on
> another pCPU. So reduce the locking section.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
> 
> Note a newline has been dropped to keep the block together.
> ---
>  xen/arch/arm/p2m.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 14791388ad..5ca7ffe41b 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1415,9 +1415,13 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  if ( v != current )
>  return NULL;
>  
> +/*
> + * The lock is here to protect us against the break-before-make
> + * sequence used when updating the entry.
> + */
>  p2m_read_lock(p2m);
> -
>  par = gvirt_to_maddr(va, , flags);
> +p2m_read_unlock(p2m);
>  
>  if ( par )
>  {
> @@ -1445,8 +1449,6 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  }
>  
>  err:
> -p2m_read_unlock(p2m);
> -
>  if ( !page && p2m->mem_access_enabled )
>  page = p2m_mem_access_check_and_get_page(va, flags, v);
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 03/15] xen/arm: Introduce helpers to clear/flags flags in HCR_EL2

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> A couple of places in the code will need to clear/set flags in HCR_EL2
> for a given vCPU and then replicate into the hardware. Introduce
> helpers and replace open-coded version.
> 
> Signed-off-by: Julien Grall 

The macros look good, but I grepped for them in your series and there
are no more callers. What places are you referring to that they will
need them?


> ---
> 
> I haven't find a good place for those new helpers so stick to
> processor.h at the moment. This require to use macro rather than inline
> helpers given that processor.h is usually the root of all headers.
> ---
>  xen/arch/arm/traps.c|  3 +--
>  xen/include/asm-arm/processor.h | 18 ++
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9ae64ae6fc..d1bf69b245 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -681,8 +681,7 @@ static void inject_vabt_exception(struct cpu_user_regs 
> *regs)
>  break;
>  }
>  
> -current->arch.hcr_el2 |= HCR_VA;
> -WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);
> +vcpu_hcr_set_flags(current, HCR_VA);
>  }
>  
>  /*
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 222a02dd99..7e695c2418 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -843,6 +843,24 @@ void abort_guest_exit_end(void);
>   : : : "memory"); \
>  } while (0)
>  
> +/*
> + * Clear/Set flags in HCR_EL2 for a given vCPU. It only supports the current
> + * vCPU for now.
> + */
> +#define vcpu_hcr_clear_flags(v, flags)  \
> +do {\
> +ASSERT((v) == current); \
> +(v)->arch.hcr_el2 &= ~(flags);  \
> +WRITE_SYSREG((v)->arch.hcr_el2, HCR_EL2);   \
> +} while (0)
> +
> +#define vcpu_hcr_set_flags(v, flags)\
> +do {\
> +ASSERT((v) == current); \
> +(v)->arch.hcr_el2 |= (flags);   \
> +WRITE_SYSREG((v)->arch.hcr_el2, HCR_EL2);   \
> +} while (0)
> +
>  #endif /* __ASSEMBLY__ */
>  #endif /* __ASM_ARM_PROCESSOR_H */
>  /*
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 02/15] xen/arm: cpregs: Fix typo in the documentation of TTBCR

[Stefano Stabellini]

On Mon, 16 Jul 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/include/asm-arm/cpregs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index 4c74e8161b..07e5791983 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -141,7 +141,7 @@
>  #define HSTRp15,4,c1,c1,3   /* Hyp. System Trap Register */
>  
>  /* CP15 CR2: Translation Table Base and Control Registers */
> -#define TTBCR   p15,0,c2,c0,2   /* Translatation Table Base Control 
> Register */
> +#define TTBCR   p15,0,c2,c0,2   /* Translation Table Base Control 
> Register */
>  #define TTBR0   p15,0,c2/* Translation Table Base Reg. 0 */
>  #define TTBR1   p15,1,c2/* Translation Table Base Reg. 1 */
>  #define HTTBR   p15,4,c2/* Hyp. Translation Table Base 
> Register */
> -- 
> 2.11.0
> 

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

[Xen-devel] [PATCH] libxl/arm: Fix build on arm64 + acpi w/ gcc 8.2

[Christopher Clark]

Add zero-padding to #defined ACPI table strings that are copied. 
Provides sufficient characters to satisfy the length required to
fully populate the destination and prevent array-bounds warnings.

Signed-off-by: Christopher Clark 
---

Please add this patch to the backport list for the next minor 4.11
release.

Prior to this: gcc 8.2 objects to memcpy past bounds:

| libxl_arm_acpi.c: In function 'make_acpi_header':
| libxl_arm_acpi.c:208:5: error: 'memcpy' forming offset [5, 6] is out
of the bounds [0, 4] [-Werror=array-bounds]
|  memcpy(h->oem_id, ACPI_OEM_ID, sizeof(h->oem_id));
|  ^
| libxl_arm_acpi.c:209:5: error: 'memcpy' forming offset [5, 8] is out
of the bounds [0, 4] [-Werror=array-bounds]
|  memcpy(h->oem_table_id, ACPI_OEM_TABLE_ID,
sizeof(h->oem_table_id));
|
^~~
| libxl_arm_acpi.c:211:5: error: 'memcpy' forming offset 4 is out of the
bounds [0, 3] [-Werror=array-bounds]
|  memcpy(h->asl_compiler_id, ACPI_ASL_COMPILER_ID,
|  ^~~~
| sizeof(h->asl_compiler_id));
| ~~~
| In function 'make_acpi_rsdp.isra.4',
| inlined from 'libxl__prepare_acpi' at libxl_arm_acpi.c:389:5:
| libxl_arm_acpi.c:193:5: error: 'memcpy' forming offset [5, 6] is out
of the bounds [0, 4] [-Werror=array-bounds]
|  memcpy(rsdp->oem_id, ACPI_OEM_ID, sizeof(rsdp->oem_id));
|  ^~~

 tools/libxl/libxl_arm_acpi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 636f724..eeca1de 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -48,9 +48,9 @@ extern const unsigned char dsdt_anycpu_arm[];
 _hidden
 extern const int dsdt_anycpu_arm_len;
 
-#define ACPI_OEM_ID "Xen"
-#define ACPI_OEM_TABLE_ID "ARM"
-#define ACPI_ASL_COMPILER_ID "XL"
+#define ACPI_OEM_ID "Xen\0\0"
+#define ACPI_OEM_TABLE_ID "ARM\0\0\0\0"
+#define ACPI_ASL_COMPILER_ID "XL\0"
 
 enum {
 RSDP,
-- 
2.7.4


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

[Xen-devel] [ovmf baseline-only test] 75068: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75068 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75068/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75062
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75062

version targeted for testing:
 ovmf 22ec06c8aaa1c4023bb7f960746da57f1b648568
baseline version:
 ovmf 1aa9314e3a84b27f74f239155fc0ec3f58b66be0

Last test of basis75062  2018-08-11 04:20:33 Z3 days
Testing same since75068  2018-08-14 09:25:22 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 
  chenc2 

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



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit 22ec06c8aaa1c4023bb7f960746da57f1b648568
Author: chenc2 
Date:   Fri Jun 29 11:39:22 2018 +0800

Vlv2TbltDevicePkg: Removing ipf which from edk2.

Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
  [Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
  of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.

Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.

Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.

Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.

Cc: David Wei 
Cc: Mang Guo 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
Reviewed-by: David Wei 

commit fda6abd64f0279b996ca6cd31e70e4ab316afe88
Author: chenc2 
Date:   Fri Jun 29 11:32:05 2018 +0800

QuarkSocPkg: Removing ipf which is no longer supported from edk2.

Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
  [Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
  of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.

Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.

Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.

Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.

Cc: Kelly Steele 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
Reviewed-by: Kelly Steele 

commit 87f9867f5536a0e498c1499c4ded73518c814464
Author: chenc2 
Date:   Fri Jun 29 11:31:36 2018 +0800

QuarkPlatformPkg: Removing ipf which is no longer supported from edk2.

Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
  

[Xen-devel] [distros-debian-snapshot test] 75067: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

flight 75067 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75067/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-daily-netboot-pygrub  broken
 test-amd64-amd64-i386-daily-netboot-pygrub 4 host-install(4) broken REGR. vs. 
75051
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail REGR. 
vs. 75051

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

baseline version:
 flight   75051

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



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


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

[Xen-devel] Xen Security Advisory 272 v2 - oxenstored does not apply quota-maxentity

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-272
  version 2

   oxenstored does not apply quota-maxentity

UPDATES IN VERSION 2


Ammend patch to reference XSA-272 in the commit message.

Public release.

ISSUE DESCRIPTION
=

The logic in oxenstored for handling writes depended on the order of
evaluation of expressions making up a tuple.

As indicated in section 7.7.3 "Operations on data structures" of the
OCaml manual:

  http://caml.inria.fr/pub/docs/manual-ocaml/expr.html

the order of evaluation of subexpressions is not specified.  In
practice, different implementations behave differently.

IMPACT
==

oxenstored may not enforce the configured quota-maxentity.

This allows a malicious or buggy guest to write as many xenstore entries
as it wishes, causing unbounded memory usage in oxenstored.  This can
lead to a system-wide DoS.

VULNERABLE SYSTEMS
==

Xen 4.1 and later are potentially vulnerable.

Only systems using the OCaml xenstored implementation are potentially
vulnerable.  Systems using the C xenstored implementation are not
vulnerable.

Whether the compiled oxenstored binary is vulnerable depends on which
compiler was used.  OCaml can be compiled either as bytecode (with
ocamlc) or as a native binary (with ocamlopt).

The following OCaml program demonstrates the issue, and identifies
whether the resulting oxenstored binary will skip the quota enforcement.

  $ cat order.ml
  let check () =
let flag = ref false in
let update _ = flag := true; () in
List.iter update [1;2;3], !flag

  let main () =
let _, flag = check () in
if flag then
print_endline "This code is not vulnerable!"
else
print_endline "This code is vulnerable!"

  let () = main ()

  $ ocamlc order.ml -o order.bytecode
  $ ./order.bytecode
  This code is vulnerable!
  $ ocamlopt order.ml -o order.native
  $ ./order.native
  This code is not vulnerable!

To confirm whether an OCaml binary is bytecode or native, use file.

  $ file order.bytecode
  order.bytecode: a /usr/bin/ocamlrun script executable (binary data)
  $ file order.native
  order.native: ELF 64-bit LSB executable, ...

NOTE: These results are applicable to OCaml 4.01.0-5 as distributed in
Debian Jessie.  These results are not representative of other versions
of OCaml, or of other OS distributions.

MITIGATION
==

There are no mitigations available.

CREDITS
===

This issue was discovered by Christian Lindig of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa272.patch   All versions of Xen

$ sha256sum xsa272*
0da953ca48d0cf0688ecff6a074304a9d2217871809a76ef26b9addeb66ecb3e  xsa272.meta
6e0359d89bf65794f16d39198cc90f5c3137bce4eb850e54625ab00e2c568c2c  xsa272.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw8fAAoJEIP+FMlX6CvZ1VYIALce26h9Sf0P0joLd/fhUwf4
JcCIaTWvHsy0ucJgpi7i+SCMa7Iz60CriK6dSYlwIuPvka8XU5MDmZ56gbENApDZ
ibWMwvyCrgb0BH3VIwJZfk7eaKM7OwKeEnnIrIWaVGsT2StwoZOHgdLRLCTSFJ/K
iss3ALSzZ8z7/WqEkBE3JeJ7skrh5nmNp428fJXWYhOyYbqkqyggn6XzBQg/EzGD
vabxz4CdYCr1ox7sq42Q/UFeLoWB6CKCLgRgqOGyCrm7K324ymBzRXtXpPUrLEaq
ugR27W/zr09e8N/fOhH4dBNCzkktuqclwrfMlFr1WUfiltSDmVwNZkURkvVGeu0=
=TPZD
-END PGP SIGNATURE-


xsa272.meta
Description: Binary data


xsa272.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 271 v2 (CVE-2018-14007) - XAPI HTTP directory traversal

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2018-14007 / XSA-271
   version 2

 XAPI HTTP directory traversal

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

XAPI has an unauthenticated HTTP endpoint update/ which exports the
contents of /var/update for other hosts to use.

However, the resolution of . and .. in paths is performed before url
unquoting is performed.  This allows an attacker to traverse out of the
web root.

IMPACT
==

An unauthenticated user with access to the management network can read
arbitrary files from the dom0 filesystem.  This includes the pool secret
/etc/xensource/ptoken which grants the attacker full administrator
access.

VULNERABLE SYSTEMS
==

All versions of XAPI since v1.13.0 are vulnerable.

If the directory /var/update doesn't exist, the vulnerability is not
exposed.

MITIGATION
==

In the recommended configuration, the management network is isolated and
isn't reachable from untrusted hosts, or by general network traffic.

CREDITS
===

This issue was discovered by Ronald Volgers of Computest
https://www.computest.nl/en/

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa271-xapi.patch

$ sha256sum xsa271*
ffefb71cd328e0ee5654c135bf9b08f48abedd013f1c68d5589132e2a03a01f8  
xsa271-xapi.patch
$

REGENERATION OF POOL SECRET
===

There are no known exploits in the wild.  If there is a risk that
credentials could have been stolen, they should be reset.

Most credentials can be reset via normal administrative means, but the
pool secret doesn't have any mechanism to reset.  The following
instructions should be used:

 1) On all pool members, stop Xapi:
# service xapi stop

 2) On the pool master:
# rm /etc/xensource/ptoken
# /opt/xensource/libexec/genptoken -f -o /etc/xensource/ptoken

 3) Copy /etc/xensource/ptoken to all pool slaves

 4) On the pool master, restart the toolstack:
# xe-toolstack-restart

 5) On all pool slaves, restart the toolstack:
# xe-toolstack-restart

Once the pool secret has been regenerated, the root password can be
changed with:
# xe user-password-change

Furthermore, consideration should be given to other credentials, such as
(but not limited to) SSL keys, Storage SAN/iSCSI/NFS details, as well as
secrets contained within VMs disks/snapshots/etc.

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw6vAAoJEIP+FMlX6CvZx6cH/0qaq4PDDHSrIONP7v35ZYWe
nZEoA+IWk0u35t4MwSRA8qcXZ9m+d7icHdE0c5Jwdh2sBOSFKzoehCuZOFXVpYTv
SHdr/J3ilZRN1KV7Zo/agZJFYClV5QxR118PnVYFqsAHVGjxh6RzazyBNPUTkoIa
qw/FBQwsib4Wkj5/RPympYscxetzAUoYiFeVtTgtqknXlt3UbXqzwg/lXTrMZwtG
nBSjFEW+EURlkKR0HF85mtFBmqA1I3xsKgJDaob5KWl+HmlIj0SY9knQ2le3lgxn
7zXiPSwOARg2E+vl3GB1Xd1fgcRGykBtjVWPX9uAgdb/C7qx6DN2PYEdyz1xZtI=
=5lIm
-END PGP SIGNATURE-


xsa271-xapi.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 268 v2 - Use of v2 grant tables may cause crash on ARM

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-268
  version 2

 Use of v2 grant tables may cause crash on ARM

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

ARM never properly implemented grant table v2, either in the
hypervisor or in Linux.

Unfortunately, an ARM guest can still request v2 grant tables; they
will simply not be properly set up, resulting in subsequent
grant-related hypercalls hitting BUG() checks.

IMPACT
==

An unprivileged guest can cause a BUG() check in the hypervisor,
resulting in a denial-of-service.

VULNERABLE SYSTEMS
==

Only ARM systems are vulnerable.  All supported versions of Xen are
vulnerable.

MITIGATION
==

None.

CREDITS
===

This issue was discovered by 王磊 of Samsung.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue by
preventing a guest from switching to grant v2.

xsa268.patch   xen-unstable
xsa268-4.11.patch  Xen 4.11.0
xsa268-4.10-?.patchXen 4.10.x
xsa268-4.9-?.patch Xen 4.9.x, Xen 4.8.x
xsa268-4.7-?.patch Xen 4.7.x
xsa268-4.6-?.patch Xen 4.6.x

$ sha256sum xsa268*
f336b45676e73f8b102e5dddf78af2d1d288f9a254142a8a8e9949db55e1cc3b  xsa268.meta
ca5f69cb8cfb74fae44a0f39f80ec9ae4d269c4895f36311b50d191be97bbcf0  xsa268.patch
93a68a5b23aedc6adf0aae23303dc8eb2c02dc40a5e1d7eb0a1b497cd66da209  
xsa268-4.6-1.patch
5b74afd13d96779a72dc34ba7c63a1735cd267fb9bb643f735ac69b0e6ff54d5  
xsa268-4.6-2.patch
820e1018f76ef2828b1cbb33e2966b99f6934a80ab55f11749ff847d375d1b02  
xsa268-4.7-1.patch
233f7e69e5fb931d2e5cf03f4407f38ff960c039c9eced957df13d3cc37fa6b1  
xsa268-4.7-2.patch
4a0c705f0266185b32daf313e686abc340e2fbb1a1644647500fc405bc180913  
xsa268-4.9-1.patch
ce16eaab94cd1e64f9c9127b64da7ebb6a7758eb540fecc3bbcc2dbfbcc4d7e2  
xsa268-4.9-2.patch
f413d41fadefe0e275c8bff16a2061bb325f3900b7ccf214a9e97fabf3ee1a89  
xsa268-4.10-1.patch
531654f82908c1aa7b0fcea818c82c4b53d4750a697db3353cc05e9e91e5d639  
xsa268-4.10-2.patch
baeb6b2c28a9cbe929c9cf34398780002fffe12b928df4d1e5951c0a5b51336a  
xsa268-4.11.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw6rAAoJEIP+FMlX6CvZ+i0H/0E0ezqXT58ivMM4QAGo5kkc
jlJH1WikhqPYEaZ2XSLDSOj9Ukllfc3WKokxMCZJzFZPtjCBFd5ClVikDNiUotl3
tOyHTh+qQrVasWWZq0MG6vg+yCMBrVXolY8K7YgfT9A+nbkzaTTsTGTMKVKZwGDI
jXoUUtkYn0n3OlnbNYYV3GcCTvfLnXxSAGzC+0NxjrKR4lXjZ/dT0U5eQerZfNha
bEsP7Stt4B+ITWNIuMxLPYGNKNHq65gaTNmBQbxRE0lRdn8N5Q5KNeccpOhOKJMi
U+ZhZ8cLEN1wNyZItO/MMB/zjVZwYaYxPYyKXAaf9uU21oOGFO6vrnF8f9oKlnQ=
=ocO0
-END PGP SIGNATURE-


xsa268.meta
Description: Binary data


xsa268.patch
Description: Binary data


xsa268-4.6-1.patch
Description: Binary data


xsa268-4.6-2.patch
Description: Binary data


xsa268-4.7-1.patch
Description: Binary data


xsa268-4.7-2.patch
Description: Binary data


xsa268-4.9-1.patch
Description: Binary data


xsa268-4.9-2.patch
Description: Binary data


xsa268-4.10-1.patch
Description: Binary data


xsa268-4.10-2.patch
Description: Binary data


xsa268-4.11.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 269 v2 - x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-269
  version 2

  x86: Incorrect MSR_DEBUGCTL handling lets guests enable BTS

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

The DEBUGCTL MSR contains several debugging features, some of which virtualise
cleanly, but some do not.  In particular, Branch Trace Store is not
virtualised by the processor, and software has to be careful to configure it
suitably not to lock up the core.  As a result, it must only be available to
fully trusted guests.

Unfortunately, in the case that vPMU is disabled, all value checking was
skipped, allowing the guest to chose any MSR_DEBUGCTL setting it likes.

IMPACT
==

A malicious or buggy guest administrator can lock up the entire host, causing
a Denial of Service.

VULNERABLE SYSTEMS
==

Xen versions 4.6 and later are vulnerable.

Only systems using Intel CPUs are affected. ARM and AMD systems are
unaffected.

Only x86 HVM or PVH guests can exploit the vulnerability.  x86 PV guests
cannot exploit the vulnerability.

MITIGATION
==

Running only x86 PV guests avoids the vulnerability.

CREDITS
===

This issue was discovered by Andrew Cooper of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa269.patch   xen-unstable
xsa269-4.11.patch  Xen 4.11
xsa269-4.10.patch  4.10, 4.9
xsa269-4.8.patch   Xen 4.8, 4.7, 4.6

$ sha256sum xsa269*
4733d09bb63523744ca2ee172e2fade0c39082c15d9a746144f279cf1359b723  xsa269.meta
5a5fe36f1f876a5029493e7fa191436fd021929aaba2d820636df17f4ed20113  xsa269.patch
ea11cef818050bca13d4eb89294627c97e4cdb830124f679e77d37a44a370286  
xsa269-4.8.patch
45ba1823530f329dd73088b77098e686b32f5daac0bc5177b2afea09f8c3593a  
xsa269-4.10.patch
e0ca060311fb9ba3247e2fe65bca4806a131644f8894fd08be374904904b1944  
xsa269-4.11.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw6sAAoJEIP+FMlX6CvZNaQIAIPnev8ld7Rt9Gaty0mymCq8
WkKMRcqqSTbmHCgFvsWPPoji9yqQZR5QMkb+q7voE7PvzqH5sTAP6i8tHtsPjZNS
jmron4grWnhoNMpM+jywIFjWyy0MT1WIDehP0GqzLIBgLODg1TIfGN1HMxBIxj5P
yC9BRiGLNkIclOKknh0Yo2fj04XX38rETpeT7J3kbfRw8wzx5sTRgoIwwkkfoqjj
GbcKSDmJmcm8OpCdl5xnMxdOxBv50p91j3VyBfOXzPeHw3sFzjURDSZgG16V5NY7
mrDzaHiRCFwdhN+k43zpyn8+A2JRI1dTz0yqGzJctyuCgFkkt4HEYLDafpeyEyg=
=CK+x
-END PGP SIGNATURE-


xsa269.meta
Description: Binary data


xsa269.patch
Description: Binary data


xsa269-4.8.patch
Description: Binary data


xsa269-4.10.patch
Description: Binary data


xsa269-4.11.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 270 v2 - Linux netback driver OOB access in hash handling

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-270
  version 2

   Linux netback driver OOB access in hash handling

UPDATES IN VERSION 2


Public release.

ISSUE DESCRIPTION
=

Linux's netback driver allows frontends to control mapping of requests
to request queues.  When processing a request to set or change this
mapping, some input validation was missing or flawed.

IMPACT
==

A malicious or buggy frontend may cause the (usually privileged)
backend to make out of bounds memory accesses, potentially resulting
in one or more of privilege escalation, Denial of Service (DoS), or
information leaks.

VULNERABLE SYSTEMS
==

Linux kernel versions from 4.7 onwards are affected.

MITIGATION
==

There is no known mitigation.

CREDITS
===

This issue was discovered by Felix Wilhelm of Google Project Zero.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa270.patch   Linux 4.7 ... 4.17

$ sha256sum xsa270*
392868c37c1fe0d16c36086208fd0fc045c1baf8ab9b207995bce72681cb8c54  xsa270.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbcw6uAAoJEIP+FMlX6CvZjxgH/iUkqOm+3T+Mr51itOmeOThy
J10GbMvqyI8kb7oTVsfHRTMU/zCm01FSCb94B9WXxrKyr3J2RCWygZpS5D5+ujkK
w8Ec3tqfRiJ6wXm+SUh+cFeiJBc4BUbTrSgc6VdtNqXO+uGB65CGVqFXTOZfSGMH
AJKXQYOYe0gLtGU+H1TrCut6IC5RQKkdbI+gCEgahgc9HnPJnOrJZYoDaXsYCt1l
gFPkd1UcVvtGbn+SUjNpXJlpWH8dY2tPeueqgu9LicGZ8jZkGI8FMCfOQ0g9dFMz
t0Q8op8N3UAVXsPws+WvbGMuZ9mF71y9y8JUZYKRdg2iLND3CRO+asaMfN+3LSk=
=gqkS
-END PGP SIGNATURE-


xsa270.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 273 v1 (CVE-2018-3620, CVE-2018-3646) - L1 Terminal Fault speculative side channel

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2018-3620,CVE-2018-3646 / XSA-273

   L1 Terminal Fault speculative side channel

ISSUE DESCRIPTION
=

In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts
due to the page being not present (e.g. paged out to disk), or because
of reserved bits being set.

Architecturally, such a memory access will result in a page fault
exception, but some processors will speculatively compute the physical
address and issue an L1D lookup.  If data resides in the L1D cache, it
may be forwarded to dependent instructions, and may be leaked via a side
channel.

Furthermore:
  * SGX protections are not applied
  * EPT guest to host translations are not applied
  * SMM protections are not applied

This issue is split into multiple CVEs depending on circumstance.  The
CVEs which apply to Xen are:
  * CVE-2018-3620 - Operating Systems and SMM
  * CVE-2018-3646 - Hypervisors

For more details, see:
  
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html

IMPACT
==

An attacker can potentially read arbitrary host RAM.  This includes data
belonging to Xen, data belonging to other guests, and data belonging to
different security contexts within the same guest.

An attacker could be a guest kernel (which can manipulate the pagetables
directly), or could be guest userspace either directly (e.g. with
mprotect() or similar system call) or indirectly (by gaming the guest
kernel's paging subsystem).

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

Only x86 processors are vulnerable.  ARM processors are not known to be
affected.

Only Intel Core based processors (from at least Merom onwards) are
potentially affected.  Other processor designs (Intel Atom/Knights
range), and other manufacturers (AMD) are not known to be affected.

x86 PV guests fall into the CVE-2018-3620 (OS and SMM) category.  x86
HVM and PVH guests fall into the CVE-2018-3646 (Hypervisors) category.

MITIGATION
==

This issue can be mitigated with a combination of software and firmware
changes.

Switching guests to being HVM with shadow paging enabled (hap=0 in
xl.cfg) is believed to mitigate the vulnerability on systems which don't
have terabytes of RAM.  However the performance impact of shadow paging
in combination with in-guests Meltdown mitigations (KPTI, KVAS, etc)
will most likely make this option prohibitive to use.

RESOLUTION
==

New microcode, and possibly a new firmware image is required to prevent
SMM data from being leaked with this vulnerability.  Consult your
hardware vendor.

Software updates to Xen (details below) are required to prevent guests
from being able to leak data belonging to Xen or to other guests in the
system.

Guest kernel software updates are required to prevent guest userspace
from being able to leak data belonging to the kernel or other processes
within the same guest.  Consult your OS vendors.

1) For PV guests (which fall into the CVE-2018-3620 - OS/SMM case),
   leakage of data from Xen or other guests can be prevented entirely
   with software changes in Xen.

   If the PV guest tries to write an L1TF-vulnerable PTE (for current
   kernels, very likely when paging data out to disk), shadow paging is
   activated and forced upon the guest.  Alternatively, if shadow paging
   is compiled out, the guest is crashed instead.

   Shadowing comes with a workload-dependent performance hit to the
   guest.  Once the guest kernel software updates have been applied, a
   well behaved guest will not write vulnerable PTEs, and will therefore
   avoid the performance penalty (or crash) entirely.

   This behaviour is active by default for guests on affected hardware
   (controlled by `pv-l1tf=`), but is disabled by default for dom0.
   Dom0's exemption is because of instabilities when being shadowed,
   which are under investigation, but dom0 kernel updates should still
   be taken to mitigate the userspace aspect.

2) For HVM and PVH guests running with Hardware Assisted Paging (which fall
   into the CVE-2018-3646 - Hypervisors case), leakage of data from Xen or
   other guests can only be prevented entirely by disabling
   SMT/Hyper-threading (if available and active in the BIOS), and by using the
   L1D_FLUSH feature (available in the new microcode) on every VMEntry.

   On affected hardware, L1D_FLUSH is enabled by default (controlled by
   `spec-ctrl=[no-]l1d-flush`), subject to microcode availability.

   However, SMT/Hyper-threading is not disabled by default, because Xen does
   not have enough information to choose an appropriate default.  Safety can
   be arranged in a number of ways by the toolstack, including with finer
   granularity than simply on or off.

   Therefore, users are expected to perform a risk assessment of their
   deployment, and explicitly chose a default (`smt=`).  See the RISK
   ASSESSMENT section 

Re: [Xen-devel] [PATCH net-next v3] xen-netfront: fix warn message as irq device name has '/'

[David Miller]

From: Xiao Liang 
Date: Tue, 14 Aug 2018 23:21:28 +0800

> There is a call trace generated after commit 
> 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file 
> found
> under /proc/irq/xx/.
> 
> This patch only picks up device type and id as its name.
> 
> With the patch, now /proc/interrupts looks like below and the warning message 
> gone:
>  70: 21  0  0  0   xen-dyn-event 
> vif0-q0-tx
>  71: 15  0  0  0   xen-dyn-event 
> vif0-q0-rx
>  72: 14  0  0  0   xen-dyn-event 
> vif0-q1-tx
>  73: 33  0  0  0   xen-dyn-event 
> vif0-q1-rx
>  74: 12  0  0  0   xen-dyn-event 
> vif0-q2-tx
>  75: 24  0  0  0   xen-dyn-event 
> vif0-q2-rx
>  76: 19  0  0  0   xen-dyn-event 
> vif0-q3-tx
>  77: 21  0  0  0   xen-dyn-event 
> vif0-q3-rx
> 
> Below is call trace information without this patch:
 ...
> Signed-off-by: Xiao Liang 
> Reviewed-by: Juergen Gross 

Applied, thank you.

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

[Xen-devel] [qemu-mainline test] 125884: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-arm64  broken

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125640
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 125640
 build-arm64   2 hosts-allocate broken REGR. vs. 125640

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 125640
 build-arm64-xsm   3 capture-logs  broken blocked in 125640
 build-arm64   3 capture-logs  broken blocked in 125640
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125640
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125640
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125640
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125640
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125640
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu6ad90805383e6d04b3ff49681b8519a48c9f4410
baseline version:
 qemuu18a398f6a39df4b08ff86ac0d38384193ca5f4cc

Last test of basis   125640  2018-07-27 22:16:44 Z   17 days
Failing since125675  2018-07-30 09:36:58 Z   15 days   10 attempts
Testing same since   125809  2018-08-08 15:11:18 Z6 days4 attempts


People who touched revisions under test:
  Alex Bennée 
  BALATON Zoltan 
  Christian Borntraeger 
  Cornelia Huck 
  David Gibson 
  Dou Liyang 
  Dr. David Alan Gilbert 
  Fam Zheng 
  Geert Uytterhoeven 
  Igor Mammedov 
  Jay Zhou 
  Kevin Wolf 
  KONRAD Frederic 
  Laurent Desnogues 
  Laurent Vivier 
  Leonid Bloch 
  liujunjie 
  Marc-André Lureau 
  Markus Armbruster 
  Max Filippov 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Pavel Dovgalyuk 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  

[Xen-devel] [PATCH net-next v3] xen-netfront: fix warn message as irq device name has '/'

[Xiao Liang]

There is a call trace generated after commit 
2d408c0d4574b01b9ed45e02516888bf925e11a9(
xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file 
found
under /proc/irq/xx/.

This patch only picks up device type and id as its name.

With the patch, now /proc/interrupts looks like below and the warning message 
gone:
 70: 21  0  0  0   xen-dyn-event 
vif0-q0-tx
 71: 15  0  0  0   xen-dyn-event 
vif0-q0-rx
 72: 14  0  0  0   xen-dyn-event 
vif0-q1-tx
 73: 33  0  0  0   xen-dyn-event 
vif0-q1-rx
 74: 12  0  0  0   xen-dyn-event 
vif0-q2-tx
 75: 24  0  0  0   xen-dyn-event 
vif0-q2-rx
 76: 19  0  0  0   xen-dyn-event 
vif0-q3-tx
 77: 21  0  0  0   xen-dyn-event 
vif0-q3-rx

Below is call trace information without this patch:

name 'device/vif/0-q0-tx'
WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
RIP: 0010:__xlate_proc_name+0x85/0xa0
RSP: 0018:b85c40473c18 EFLAGS: 00010286
RAX:  RBX: 0006 RCX: 0006
RDX: 0007 RSI: 0096 RDI: 984c7f516930
RBP: b85c40473cb8 R08: 002c R09: 0229
R10:  R11: 0001 R12: b85c40473c98
R13: b85c40473cb8 R14: b85c40473c50 R15: 
FS:  () GS:984c7f50() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f69b6899038 CR3: 1c20a006 CR4: 001606e0
Call Trace:
__proc_create+0x45/0x230
? snprintf+0x49/0x60
proc_mkdir_data+0x35/0x90
register_handler_proc+0xef/0x110
? proc_register+0xfc/0x110
? proc_create_data+0x70/0xb0
__setup_irq+0x39b/0x660
? request_threaded_irq+0xad/0x160
request_threaded_irq+0xf5/0x160
? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
bind_evtchn_to_irqhandler+0x3d/0x70
? xenbus_alloc_evtchn+0x41/0xa0
netback_changed+0xa46/0xcda [xen_netfront]
? find_watch+0x40/0x40
xenwatch_thread+0xc5/0x160
? finish_wait+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 
5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 
5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
---[ end trace 650e5561b0caab3a ]---

Signed-off-by: Xiao Liang 
Reviewed-by: Juergen Gross 
---
 drivers/net/xen-netfront.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 799cba4624a5..c4955bd303bb 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1604,14 +1604,16 @@ static int xennet_init_queue(struct netfront_queue 
*queue)
 {
unsigned short i;
int err = 0;
+   char *devid;
 
spin_lock_init(>tx_lock);
spin_lock_init(>rx_lock);
 
timer_setup(>rx_refill_timer, rx_refill_timeout, 0);
 
-   snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->xbdev->nodename, queue->id);
+   devid = strrchr(queue->info->xbdev->nodename, '/') + 1;
+   snprintf(queue->name, sizeof(queue->name), "vif%s-q%u",
+devid, queue->id);
 
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
-- 
2.17.1


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

Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:09AM +0100, Andrew Cooper wrote:
> For ARM, the call to arch_domain_create() needs to have completed before
> domain_max_vcpus() will return the correct upper bound.
> 
> For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation
> of dom0->vcpu.
> 
> With d->max_vcpus now correctly configured before evtchn_init(), the poll mask
> can be constructed suitably for the domain, rather than for the worst-case
> setting.
> 
> Due to the evtchn_init() fixes, it no longer calls domain_max_vcpus(), and
> ARM's two implementations of vgic_max_vcpus() no longer need work around the
> out-of-order call.
> 
> From this point on, d->max_vcpus and d->vcpus[] are valid for any domain which
> can be looked up by domid.
> 
> The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call attempt with
> max != d->max_vcpus, which does match the older semantics (not that it is
> obvious from the code).  The logic to allocate d->vcpu[] is dropped, but at
> this point the hypercall still needs making to allocate each vcpu.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Wei Liu 
> 
> v2:
>  * Allocate in domain_create() rather than arch_domain_create().
>  * Retain domain_max_vcpus().
> ---
>  xen/arch/arm/domain_build.c |  8 +---
>  xen/arch/arm/setup.c|  2 +-
>  xen/arch/arm/vgic.c | 11 +--
>  xen/arch/arm/vgic/vgic.c| 22 +-
>  xen/arch/x86/dom0_build.c   |  8 +---
>  xen/arch/x86/setup.c|  2 +-
>  xen/common/domain.c | 18 ++
>  xen/common/domctl.c | 39 +--
>  xen/common/event_channel.c  |  3 +--
>  xen/include/xen/domain.h|  2 +-
>  10 files changed, 27 insertions(+), 88 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index f4a1225..6f45e56 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -72,14 +72,8 @@ unsigned int __init dom0_max_vcpus(void)
>  return opt_dom0_max_vcpus;
>  }
>  
> -struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
> - unsigned int max_vcpus)
> +struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
>  {
> -dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
> -if ( !dom0->vcpu )
> -return NULL;
> -dom0->max_vcpus = max_vcpus;
> -
>  return alloc_vcpu(dom0, 0, 0);
>  }
>  
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 72e42e8..a3e1ef7 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -863,7 +863,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>  dom0_cfg.max_vcpus = dom0_max_vcpus();
>  
>  dom0 = domain_create(0, _cfg, true);
> -if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0, dom0_cfg.max_vcpus) == 
> NULL) )
> +if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
>  panic("Error creating domain 0");
>  
>  if ( construct_dom0(dom0) != 0)
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 7a2c455..5a4f082 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -669,16 +669,7 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
>  
>  unsigned int vgic_max_vcpus(const struct domain *d)
>  {
> -/*
> - * Since evtchn_init would call domain_max_vcpus for poll_mask
> - * allocation when the vgic_ops haven't been initialised yet,
> - * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
> - */
> -if ( !d->arch.vgic.handler )
> -return MAX_VIRT_CPUS;
> -else
> -return min_t(unsigned int, MAX_VIRT_CPUS,
> - d->arch.vgic.handler->max_vcpus);
> +return min_t(unsigned int, MAX_VIRT_CPUS, 
> d->arch.vgic.handler->max_vcpus);
>  }
>  
>  /*
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index 832632a..4124817 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -951,27 +951,7 @@ void vgic_sync_hardware_irq(struct domain *d,
>  
>  unsigned int vgic_max_vcpus(const struct domain *d)
>  {
> -unsigned int vgic_vcpu_limit;
> -
> -switch ( d->arch.vgic.version )
> -{
> -case GIC_INVALID:
> -/*
> - * Since evtchn_init would call domain_max_vcpus for poll_mask
> - * allocation before the VGIC has been initialised, we need to
> - * return some safe value in this case. As this is for allocation
> - * purposes, go with the maximum value.
> - */
> -vgic_vcpu_limit = MAX_VIRT_CPUS;
> -break;
> -case GIC_V2:
> -vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
> -break;
> -default:
> -BUG();
> -}
> -
> -return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
> +return min_t(unsigned int, MAX_VIRT_CPUS, 
> d->arch.vgic.handler->max_vcpus);
>  }

Since both implementations are equal now, 

Re: [Xen-devel] [PATCH v2 11/12] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:08AM +0100, Andrew Cooper wrote:
> Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting
> the existing alloc_dom0_vcpu0() function in half.
> 
> As domain_create() doesn't yet set up the vcpu array, the max value is also
> passed into alloc_dom0_vcpu0().  This is temporary for bisectibility and
> removed in the following patch.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Julien Grall 

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v2 09/12] xen/domain: Call arch_domain_create() as early as possible in domain_create()

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:06AM +0100, Andrew Cooper wrote:
> This is in preparation to set up d->max_cpus and d->vcpu[] in domain_create(),
> and allow later parts of domain construction to have access to the values.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Wei Liu 
> ---
>  xen/common/domain.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index be51426..0c44f27 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -322,6 +322,23 @@ struct domain *domain_create(domid_t domid,
>  else
>  d->guest_type = guest_type_pv;
>  
> +if ( !is_hardware_domain(d) )
> +d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
> +else
> +d->nr_pirqs = extra_hwdom_irqs ? nr_static_irqs + 
> extra_hwdom_irqs
> +   : arch_hwdom_irqs(domid);
> +if ( d->nr_pirqs > nr_irqs )
> +d->nr_pirqs = nr_irqs;

d->nr_pirqs = min(d->nr_pirqs, nr_irqs);

LGTM:

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH] xen: fix stale PVH comment

[Wei Liu]

On Tue, Aug 14, 2018 at 04:03:24PM +0200, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 08/12] xen/gnttab: Fold grant_table_{create, set_limits}() into grant_table_init()

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:05AM +0100, Andrew Cooper wrote:
> Now that the max_{grant,maptrack}_frames are specified from the very beginning
> of grant table construction, the various initialisation functions can be
> folded together and simplified as a result.
> 
> Leave grant_table_init() as the public interface, which is more consistent
> with other subsystems.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

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

[Xen-devel] [GIT PULL] xen: features and fixes for 4.19-rc1

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.19-rc1-tag

xen: features and fixes for 4.19-rc1

It contains the following:

- a series to add dma-buf functionality to Xen grant table handling
- a fix for booting the kernel as Xen PVH dom0
- a fix for booting the kernel as a Xen PV guest with CONFIG_DEBUG_VIRTUAL
  enabled
- some other minor performance and style fixes


Thanks.

Juergen

 arch/x86/include/asm/xen/hypercall.h |  25 +-
 arch/x86/kernel/cpu/common.c |   2 +-
 arch/x86/kernel/cpu/cpu.h|   1 +
 arch/x86/xen/enlighten_pv.c  |   3 +
 arch/x86/xen/multicalls.c|   6 +-
 arch/x86/xen/spinlock.c  |   4 +
 drivers/xen/Kconfig  |  24 +
 drivers/xen/Makefile |   2 +
 drivers/xen/balloon.c|  75 +--
 drivers/xen/biomerge.c   |   2 +-
 drivers/xen/gntdev-common.h  |  94 
 drivers/xen/gntdev-dmabuf.c  | 857 +++
 drivers/xen/gntdev-dmabuf.h  |  33 ++
 drivers/xen/gntdev.c | 220 ++---
 drivers/xen/grant-table.c| 151 +-
 drivers/xen/mem-reservation.c| 118 +
 drivers/xen/xen-balloon.c|   2 +-
 include/uapi/xen/gntdev.h| 106 +
 include/xen/grant_table.h|  21 +
 include/xen/mem-reservation.h|  59 +++
 20 files changed, 1634 insertions(+), 171 deletions(-)

Colin Ian King (1):
  xen/gntdev: don't dereference a null gntdev_dmabuf on allocation failure

Gustavo A. R. Silva (1):
  xen/biomerge: Use true and false for boolean values

Juergen Gross (2):
  xen: don't use privcmd_call() from xen_mc_flush()

M. Vefa Bicakci (1):
  xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

Oleksandr Andrushchenko (8):
  xen/grant-table: Make set/clear page private code shared
  xen/balloon: Share common memory reservation routines
  xen/grant-table: Allow allocating buffers suitable for DMA
  xen/gntdev: Allow mappings for DMA buffers
  xen/gntdev: Make private routines/structures accessible
  xen/gntdev: Add initial support for dma-buf UAPI
  xen/gntdev: Implement dma-buf export functionality
  xen/gntdev: Implement dma-buf import functionality

Roger Pau Monne (1):
  xen/balloon: fix balloon initialization for PVH Dom0

Waiman Long (1):
  xen/spinlock: Don't use pvqspinlock if only 1 vCPU

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

Re: [Xen-devel] [PATCH v2 07/12] xen/domctl: Remove XEN_DOMCTL_set_gnttab_limits

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:04AM +0100, Andrew Cooper wrote:
> Now that XEN_DOMCTL_createdomain handles the grant table limits, remove
> XEN_DOMCTL_set_gnttab_limits (including XSM hooks and libxc wrappers).
> 
> Signed-off-by: Andrew Cooper 
> Acked-by: Daniel De Graaf 
> Acked-by: Wei Liu 

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:03AM +0100, Andrew Cooper wrote:
> ... rather than setting the limits up after domain_create() has completed.
> 
> This removes all the gnttab infrastructure for calculating the number of dom0
> grant frames, opting instead to require the dom0 construction code to pass a
> sane value in via the configuration.
> 
> In practice, this now means that there is never a partially constructed grant
> table for a reference-able domain.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Wei Liu 
> 
> v2:
>  * Split/rearrange to avoid the post-domain-create error path.
> ---
>  xen/arch/arm/domain_build.c   |  3 ++-
>  xen/arch/arm/setup.c  | 12 
>  xen/arch/x86/setup.c  |  3 +++
>  xen/common/domain.c   |  3 ++-
>  xen/common/grant_table.c  | 16 +++-
>  xen/include/asm-arm/grant_table.h | 12 
>  xen/include/asm-x86/grant_table.h |  5 -
>  xen/include/xen/grant_table.h |  6 ++
>  8 files changed, 24 insertions(+), 36 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 1351572..737e0f3 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2079,7 +2079,8 @@ static void __init find_gnttab_region(struct domain *d,
>   * enough space for a large grant table
>   */
>  kinfo->gnttab_start = __pa(_stext);
> -kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
> +kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
> +   PFN_DOWN(_etext - _stext)) << PAGE_SHIFT;
>  
>  #ifdef CONFIG_ARM_32
>  /*
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 45f3841..3d3b30c 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -693,6 +694,17 @@ void __init start_xen(unsigned long boot_phys_offset,
>  struct domain *dom0;
>  struct xen_domctl_createdomain dom0_cfg = {
>  .max_evtchn_port = -1,
> +
> +/*
> + * The region used by Xen on the memory will never be mapped in DOM0
> + * memory layout. Therefore it can be used for the grant table.
> + *
> + * Only use the text section as it's always present and will contain
> + * enough space for a large grant table
> + */
> +.max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
> +  PFN_DOWN(_etext - _stext)),

You have this calculation here and in the chunk above. Maybe you want
to keep gnttab_dom0_max (or something similar with the min included)
in order to avoid open coding this calculation twice?

The rest LGTM:

Reviewed-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH v2 04/12] xen/evtchn: Pass max_evtchn_port into evtchn_init()

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:01AM +0100, Andrew Cooper wrote:
> ... rather than setting it up once domain_create() has completed.  This
> involves constructing a default value for dom0.
> 
> No practical change in functionality.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

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

[Xen-devel] [PATCH] xen: fix stale PVH comment

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/public/domctl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 5c3916caaf..ad95a8e644 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -49,7 +49,7 @@ struct xen_domctl_createdomain {
 /* IN parameters */
 uint32_t ssidref;
 xen_domain_handle_t handle;
- /* Is this an HVM guest (as opposed to a PVH or PV guest)? */
+ /* Is this an HVM guest (as opposed to a PV guest)? */
 #define _XEN_DOMCTL_CDF_hvm_guest 0
 #define XEN_DOMCTL_CDF_hvm_guest  (1U<<_XEN_DOMCTL_CDF_hvm_guest)
  /* Use hardware-assisted paging if available? */
-- 
2.18.0


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

Re: [Xen-devel] [PATCH v2 03/12] xen/domctl: Merge set_max_evtchn into createdomain

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 11:01:00AM +0100, Andrew Cooper wrote:
> set_max_evtchn is somewhat weird.  It was introduced with the event_fifo work,
> but has never been used.  Still, it is a bounding on resources consumed by the
> event channel infrastructure, and should be part of createdomain, rather than
> editable after the fact.
> 
> Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
> wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
> 
> Signed-off-by: Andrew Cooper 
> Acked-by: Daniel De Graaf 
> Acked-by: Christian Lindig 
> Acked-by: Wei Liu 

Reviewed-by: Roger Pau Monné 

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

[Xen-devel] [PATCH v5 6/8] dom0/pvh: change the order of the MMCFG initialization

[Roger Pau Monne]

So it's done before the iommu is initialized. This is required in
order to be able to fetch the MMCFG regions from the domain struct.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - New in this version.
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dom0_build.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index f0cd63b1ec..5065729106 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1100,6 +1100,13 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
+/*
+ * NB: MMCFG initialization needs to be performed before iommu
+ * initialization so the iommu code can fetch the MMCFG regions used by the
+ * domain.
+ */
+pvh_setup_mmcfg(d);
+
 iommu_hwdom_init(d);
 
 rc = pvh_load_kernel(d, image, image_headroom, initrd, 
bootstrap_map(image),
@@ -1124,8 +1131,6 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
-pvh_setup_mmcfg(d);
-
 printk("WARNING: PVH is an experimental mode with limited 
functionality\n");
 return 0;
 }
-- 
2.18.0


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

[Xen-devel] [PATCH v5 3/8] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu

[Roger Pau Monne]

Introduce a new dom0-iommu=map-inclusive generic option that
supersedes iommu_inclusive_mapping. The previous behavior is preserved
and the option should only be enabled by default on Intel hardware.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Paul Durrant 
---
Changes since v4:
 - Use an if to set the default option value.
 - Set the option to false unconditionally on ARM.

Changes since v2:
 - Fix typo in commit message.
 - Change style and text of the documentation in xen command line.
 - Set the defaults in {intel/amd}_iommu_hwdom_init for inclusive.
 - Re-add the iommu_dom0_passthrough || !is_pv_domain(d) check.

Changes since v1:
 - Use dom0-iommu instead of the iommu option.
 - Only enable by default on Intel hardware.
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
Cc: Kevin Tian 
---
 docs/misc/xen-command-line.markdown | 13 -
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 ++
 xen/drivers/passthrough/arm/iommu.c |  4 ++
 xen/drivers/passthrough/arm/smmu.c  |  2 +
 xen/drivers/passthrough/iommu.c | 12 +
 xen/drivers/passthrough/vtd/extern.h|  2 -
 xen/drivers/passthrough/vtd/iommu.c |  8 ++-
 xen/drivers/passthrough/vtd/x86/vtd.c   | 58 +---
 xen/drivers/passthrough/x86/iommu.c | 59 +
 xen/include/xen/iommu.h |  2 +
 10 files changed, 99 insertions(+), 65 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0292f9bb03..11b11a017e 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -682,7 +682,7 @@ Flag that makes a dom0 use shadow paging. Only works when 
"pvh" is
 enabled.
 
 ### dom0-iommu
-> `= List of [ passthrough | strict ]`
+> `= List of [ passthrough | strict | map-inclusive ]`
 
 This list of booleans control the iommu usage by Dom0:
 
@@ -694,6 +694,14 @@ This list of booleans control the iommu usage by Dom0:
   `true` for a PVH Dom0 and any attempt to overwrite it from the command line
   is ignored.
 
+* `map-inclusive`: sets up DMA remapping for all the non-RAM regions below 4GB
+  except for unusable ranges. Use this to work around firmware issues providing
+  incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for IOMMU
+  accesses for Dom0, with this option all pages up to 4GB, not marked as
+  unusable in the E820 table, will get a mapping established. Note that this
+  option is only applicable to a PV Dom0 and is enabled by default on Intel
+  hardware.
+
 ### dom0\_ioports\_disable (x86)
 > `= List of -`
 
@@ -1229,6 +1237,9 @@ wait descriptor timed out', try increasing this value.
 ### iommu\_inclusive\_mapping (VT-d)
 > `= `
 
+**WARNING: This command line option is deprecated, and superseded by
+_dom0-iommu=map-inclusive_ - using both options in combination is undefined.**
+
 > Default: `true`
 
 Use this to work around firmware issues providing incorrect RMRR entries.
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index ab39e7500d..27eb49619d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -253,6 +253,10 @@ static void __hwdom_init amd_iommu_hwdom_init(struct 
domain *d)
 unsigned long i; 
 const struct amd_iommu *iommu;
 
+/* Inclusive IOMMU mappings are disabled by default on AMD hardware. */
+if ( iommu_hwdom_inclusive == -1 )
+iommu_hwdom_inclusive = false;
+
 if ( allocate_domain_resources(dom_iommu(d)) )
 BUG();
 
diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c
index 95b1abb972..325997b19f 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,7 @@ int arch_iommu_populate_page_table(struct domain *d)
 /* The IOMMU shares the p2m with the CPU */
 return -ENOSYS;
 }
+
+void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
+{
+}
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 74c09b0991..b142677b8c 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2727,6 +2727,8 @@ static int arm_smmu_iommu_domain_init(struct domain *d)
 
 static void __hwdom_init arm_smmu_iommu_hwdom_init(struct domain *d)
 {
+   /* Set to false options not supported on ARM. */
+   iommu_hwdom_inclusive = false;
 }
 
 static void arm_smmu_iommu_domain_teardown(struct domain *d)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 6c3aa904dc..4cc29eeb2c 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -61,6 +61,7 @@ bool_t __read_mostly iommu_intremap = 1;
 
 bool __hwdom_initdata 

[Xen-devel] [PATCH v5 8/8] x86/iommu: add map-reserved dom0-iommu option to map reserved memory ranges

[Roger Pau Monne]

Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this is however limited to Intel hardware and quite
cumbersome to do.

In order to solve those issues add a new dom0-iommu=map-reserved
option that identity maps all regions marked as reserved in the memory
map.  Note that regions used by devices emulated by Xen (LAPIC,
IO-APIC or PCIe MCFG regions) are specifically avoided. Note that this
option is available to a PVH Dom0 (as opposed to the inclusive option
which only works for PV Dom0).

Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Use pfn_to_paddr.
 - Rebase on top of previous changes.
 - Change the default option setting to use if instead of a ternary
   operator.
 - Rename to map-reserved.

Changes since v3:
 - Add mappings if the iommu page tables are shared.

Changes since v2:
 - Fix comment regarding dom0-strict.
 - Change documentation style of xen command line.
 - Rename iommu_map to hwdom_iommu_map.
 - Move all the checks to hwdom_iommu_map.

Changes since v1:
 - Introduce a new reserved option instead of abusing the inclusive
   option.
 - Use the same helper function for PV and PVH in order to decide if a
   page should be added to the domain page tables.
 - Use the data inside of the domain struct to detect overlaps with
   emulated MMIO regions.
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/xen-command-line.markdown |  9 
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  3 ++
 xen/drivers/passthrough/arm/smmu.c  |  1 +
 xen/drivers/passthrough/iommu.c |  3 ++
 xen/drivers/passthrough/vtd/iommu.c |  3 ++
 xen/drivers/passthrough/x86/iommu.c | 50 ++---
 xen/include/xen/iommu.h |  2 +-
 7 files changed, 65 insertions(+), 6 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 11b11a017e..0601d3005d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -702,6 +702,15 @@ This list of booleans control the iommu usage by Dom0:
   option is only applicable to a PV Dom0 and is enabled by default on Intel
   hardware.
 
+* `map-reserved`: sets up DMA remapping for all the reserved regions in the
+  memory map for Dom0. Use this to work around firmware issues providing
+  incorrect RMRR/IVMD entries. Rather than only mapping RAM pages for IOMMU
+  accesses for Dom0, all memory regions marked as reserved in the memory map
+  that don't overlap with any MMIO region from emulated devices will be
+  identity mapped. This option maps a subset of the memory that would be
+  mapped when using the `map-inclusive` option. This option is available to a
+  PVH Dom0 and is enabled by default on Intel hardware.
+
 ### dom0\_ioports\_disable (x86)
 > `= List of -`
 
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 27eb49619d..49d934e1ac 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -256,6 +256,9 @@ static void __hwdom_init amd_iommu_hwdom_init(struct domain 
*d)
 /* Inclusive IOMMU mappings are disabled by default on AMD hardware. */
 if ( iommu_hwdom_inclusive == -1 )
 iommu_hwdom_inclusive = false;
+/* Reserved IOMMU mappings are disabled by default on AMD hardware. */
+if ( iommu_hwdom_reserved == -1 )
+iommu_hwdom_reserved = false;
 
 if ( allocate_domain_resources(dom_iommu(d)) )
 BUG();
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index b142677b8c..8ea39659d1 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2729,6 +2729,7 @@ static void __hwdom_init arm_smmu_iommu_hwdom_init(struct 
domain *d)
 {
/* Set to false options not supported on ARM. */
iommu_hwdom_inclusive = false;
+   iommu_hwdom_reserved = false;
 }
 
 static void arm_smmu_iommu_domain_teardown(struct domain *d)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4cc29eeb2c..c33ddb9ff7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -62,6 +62,7 @@ bool_t __read_mostly iommu_intremap = 1;
 bool __hwdom_initdata iommu_hwdom_strict;
 bool __read_mostly iommu_hwdom_passthrough;
 int8_t __hwdom_initdata iommu_hwdom_inclusive = -1;
+int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
 
 /*
  * In the current implementation of VT-d posted interrupts, in some extreme
@@ -155,6 +156,8 @@ static int __init parse_dom0_iommu_param(const char *s)
 

[Xen-devel] [PATCH v5 7/8] vpci: introduce a helper to check MMCFG ranges

[Roger Pau Monne]

The helpers returns whether a given memory address belongs to a domain
MMCFG range.

Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - New in this version.
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/io.c| 5 +
 xen/include/asm-x86/hvm/io.h | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index bf4d8748d3..1f8fe36168 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -404,6 +404,11 @@ static const struct hvm_mmcfg *vpci_mmcfg_find(const 
struct domain *d,
 return NULL;
 }
 
+bool vpci_is_mmcfg_address(const struct domain *d, paddr_t addr)
+{
+return vpci_mmcfg_find(d, addr);
+}
+
 static unsigned int vpci_mmcfg_decode_addr(const struct hvm_mmcfg *mmcfg,
paddr_t addr, pci_sbdf_t *sbdf)
 {
diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h
index e6b6ed0b92..83431b44f2 100644
--- a/xen/include/asm-x86/hvm/io.h
+++ b/xen/include/asm-x86/hvm/io.h
@@ -180,6 +180,9 @@ int register_vpci_mmcfg_handler(struct domain *d, paddr_t 
addr,
 /* Destroy tracked MMCFG areas. */
 void destroy_vpci_mmcfg(struct domain *d);
 
+/* Check if an address is between a MMCFG region for a domain. */
+bool vpci_is_mmcfg_address(const struct domain *d, paddr_t addr);
+
 #endif /* __ASM_X86_HVM_IO_H__ */
 
 
-- 
2.18.0


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

[Xen-devel] [PATCH v5 4/8] mm: introduce a helper to get the memory type of a page

[Roger Pau Monne]

The type is only returned if the full page has the same type. This
function is unimplemented for ARM.

Signed-off-by: Roger Pau Monné 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/arm/mm.c|  6 ++
 xen/arch/x86/mm.c| 34 ++
 xen/include/xen/mm.h |  2 ++
 3 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index d234c46e41..f734b9287a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1181,6 +1181,12 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
mem_type)
 return 0;
 }
 
+int page_get_type(unsigned long mfn)
+{
+ASSERT_UNREACHABLE();
+return -1;
+}
+
 unsigned long domain_get_maximum_gpfn(struct domain *d)
 {
 return gfn_x(d->arch.p2m.max_mapped_gfn);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a1a1f5f3c3..cb4b68b2a9 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -430,6 +430,40 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
mem_type)
 return 0;
 }
 
+int page_get_type(unsigned long mfn)
+{
+uint64_t maddr = pfn_to_paddr(mfn);
+unsigned int i;
+
+for ( i = 0; i < e820.nr_map; i++ )
+{
+/* Test the range. */
+if ( (e820.map[i].addr <= maddr) &&
+ ((e820.map[i].addr + e820.map[i].size) >= (maddr + PAGE_SIZE)) )
+switch ( e820.map[i].type )
+{
+case E820_RAM:
+return RAM_TYPE_CONVENTIONAL;
+
+case E820_RESERVED:
+return RAM_TYPE_RESERVED;
+
+case E820_UNUSABLE:
+return RAM_TYPE_UNUSABLE;
+
+case E820_ACPI:
+case E820_NVS:
+return RAM_TYPE_ACPI;
+
+default:
+ASSERT_UNREACHABLE();
+return -1;
+}
+}
+
+return -1;
+}
+
 unsigned long domain_get_maximum_gpfn(struct domain *d)
 {
 if ( is_hvm_domain(d) )
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 24654e8e22..9584fe3a77 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -597,6 +597,8 @@ int __must_check donate_page(struct domain *d, struct 
page_info *page,
 #define RAM_TYPE_ACPI 0x0008
 /* TRUE if the whole page at @mfn is of the requested RAM type(s) above. */
 int page_is_ram_type(unsigned long mfn, unsigned long mem_type);
+/* Returns the page type if the whole page is of the same type. */
+int page_get_type(unsigned long mfn);
 
 /* Prepare/destroy a ring for a dom0 helper. Helper with talk
  * with Xen on behalf of this domain. */
-- 
2.18.0


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

[Xen-devel] [PATCH v5 2/8] iommu: introduce dom0-iommu option

[Roger Pau Monne]

To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.

Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Move the iommu_dom0_* variable renaming to a previous patch.
 - Use dom0-iommu=passthrough|strict booleans, like the iommu option
   used.

Changes since v2:
 - Change the style and text used in the xen command line document.
 - Don't allow none, strict or relaxed to use the no- prefix.

Changes since v1:
 - New in this version.
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/xen-command-line.markdown | 19 +++
 xen/drivers/passthrough/iommu.c | 26 ++
 2 files changed, 45 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 65b4754418..0292f9bb03 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -681,6 +681,19 @@ Flag that makes a dom0 boot in PVHv2 mode.
 Flag that makes a dom0 use shadow paging. Only works when "pvh" is
 enabled.
 
+### dom0-iommu
+> `= List of [ passthrough | strict ]`
+
+This list of booleans control the iommu usage by Dom0:
+
+* `passthrough`: disables DMA remapping for Dom0. Default is `false`.
+
+* `strict`: sets up DMA remapping only for the RAM Dom0 actually got assigned.
+  Default is `false` which means Dom0 will get mappings for all the host
+  RAM except regions in use by Xen. Note that this option is hard coded to
+  `true` for a PVH Dom0 and any attempt to overwrite it from the command line
+  is ignored.
+
 ### dom0\_ioports\_disable (x86)
 > `= List of -`
 
@@ -1150,12 +1163,18 @@ detection of systems known to misbehave upon accesses 
to that port.
 
 > `dom0-passthrough`
 
+> **WARNING: This command line option is deprecated, and superseded by
+> _dom0-iommu=passthrough_ - using both options in combination is undefined.**
+
 > Default: `false`
 
 >> Control whether to disable DMA remapping for Dom0.
 
 > `dom0-strict`
 
+> **WARNING: This command line option is deprecated, and superseded by
+> _dom0-iommu=strict_ - using both options in combination is undefined.**
+
 > Default: `false`
 
 >> Control whether to set up DMA remapping only for the memory Dom0 actually
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 06b77eaa31..6c3aa904dc 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -136,6 +136,32 @@ static int __init parse_iommu_param(const char *s)
 return rc;
 }
 
+static int __init parse_dom0_iommu_param(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+int val;
+
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( (val = parse_boolean("passthrough", s, ss)) >= 0 )
+iommu_hwdom_passthrough = val;
+else if ( (val = parse_boolean("strict", s, ss)) >= 0 )
+iommu_hwdom_strict = val;
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("dom0-iommu", parse_dom0_iommu_param);
+
 int iommu_domain_init(struct domain *d)
 {
 struct domain_iommu *hd = dom_iommu(d);
-- 
2.18.0


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

[Xen-devel] [PATCH v5 0/8] x86/iommu: PVH Dom0 workarounds for missing RMRR entries

[Roger Pau Monne]

Hello,

The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.

The PVH workaround identity maps all regions marked as reserved in the
memory map.

Note that this workaround is enabled by default on Intel hardware. It's
also available to AMD hardware, although it's disabled by default in
that case.

The series can be found at:

git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v5

Thanks.

Roger Pau Monne (8):
  iommu: rename iommu_dom0_strict and iommu_passthrough
  iommu: introduce dom0-iommu option
  iommu: make iommu_inclusive_mapping a suboption of dom0-iommu
  mm: introduce a helper to get the memory type of a page
  x86/iommu: switch the hwdom mapping function to use page_get_type
  dom0/pvh: change the order of the MMCFG initialization
  vpci: introduce a helper to check MMCFG ranges
  x86/iommu: add map-reserved dom0-iommu option to map reserved memory
ranges

 docs/misc/xen-command-line.markdown |  39 
 xen/arch/arm/mm.c   |   6 ++
 xen/arch/x86/hvm/dom0_build.c   |   9 +-
 xen/arch/x86/hvm/io.c   |   5 +
 xen/arch/x86/mm.c   |  34 +++
 xen/arch/x86/x86_64/mm.c|   3 +-
 xen/drivers/passthrough/amd/iommu_init.c|   2 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  11 ++-
 xen/drivers/passthrough/arm/iommu.c |   4 +
 xen/drivers/passthrough/arm/smmu.c  |   3 +
 xen/drivers/passthrough/iommu.c |  68 ++---
 xen/drivers/passthrough/vtd/extern.h|   2 -
 xen/drivers/passthrough/vtd/iommu.c |  25 ++---
 xen/drivers/passthrough/vtd/x86/vtd.c   |  58 +--
 xen/drivers/passthrough/x86/iommu.c | 103 
 xen/include/asm-x86/hvm/io.h|   3 +
 xen/include/xen/iommu.h |   8 +-
 xen/include/xen/mm.h|   2 +
 18 files changed, 293 insertions(+), 92 deletions(-)

-- 
2.18.0


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

[Xen-devel] [PATCH v5 5/8] x86/iommu: switch the hwdom mapping function to use page_get_type

[Roger Pau Monne]

This avoids repeated calls to page_is_ram_type which improves
performance and makes the code easier to read.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - New in this version.
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/x86/iommu.c | 60 +++--
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index 25e1ebf8b3..36ec5c4f54 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -134,6 +134,37 @@ void arch_iommu_domain_destroy(struct domain *d)
 {
 }
 
+static bool __hwdom_init hwdom_iommu_map(const struct domain *d,
+ unsigned long pfn,
+ unsigned long max_pfn)
+{
+/*
+ * Set up 1:1 mapping for dom0. Default to include only conventional RAM
+ * areas and let RMRRs include needed reserved regions. When set, the
+ * inclusive mapping additionally maps in every pfn up to 4GB except those
+ * that fall in unusable ranges.
+ */
+if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) || xen_in_range(pfn) )
+return false;
+
+switch ( page_get_type(pfn) )
+{
+case RAM_TYPE_UNUSABLE:
+return false;
+
+case RAM_TYPE_CONVENTIONAL:
+if ( iommu_hwdom_strict )
+return false;
+break;
+
+default:
+if ( !iommu_hwdom_inclusive || pfn > max_pfn )
+return false;
+}
+
+return true;
+}
+
 void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
 {
 unsigned long i, top, max_pfn;
@@ -149,36 +180,9 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
 for ( i = 0; i < top; i++ )
 {
 unsigned long pfn = pdx_to_pfn(i);
-bool map;
 int rc;
 
-/*
- * Set up 1:1 mapping for dom0. Default to include only
- * conventional RAM areas and let RMRRs include needed reserved
- * regions. When set, the inclusive mapping additionally maps in
- * every pfn up to 4GB except those that fall in unusable ranges.
- */
-if ( pfn > max_pfn && !mfn_valid(_mfn(pfn)) )
-continue;
-
-if ( iommu_hwdom_inclusive && pfn <= max_pfn )
-map = !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
-else
-map = page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
-
-if ( !map )
-continue;
-
-/* Exclude Xen bits */
-if ( xen_in_range(pfn) )
-continue;
-
-/*
- * If dom0-strict mode is enabled then exclude conventional RAM
- * and let the common code map dom0's pages.
- */
-if ( iommu_hwdom_strict &&
- page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
+if ( !hwdom_iommu_map(d, pfn, max_pfn) )
 continue;
 
 rc = iommu_map_page(d, pfn, pfn, IOMMUF_readable|IOMMUF_writable);
-- 
2.18.0


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

[Xen-devel] [PATCH v5 1/8] iommu: rename iommu_dom0_strict and iommu_passthrough

[Roger Pau Monne]

To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
descriptive of their usage. Also change their type from bool_t to
bool.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
Cc: Kevin Tian 
---
Changes since v4:
 - New in this version.
---
 xen/arch/x86/x86_64/mm.c|  3 ++-
 xen/drivers/passthrough/amd/iommu_init.c|  2 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  4 +--
 xen/drivers/passthrough/iommu.c | 27 +++--
 xen/drivers/passthrough/vtd/iommu.c | 16 ++--
 xen/drivers/passthrough/vtd/x86/vtd.c   |  2 +-
 xen/include/xen/iommu.h |  6 +++--
 7 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cca4ae926e..093ad5dab1 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1426,7 +1426,8 @@ int memory_add(unsigned long spfn, unsigned long epfn, 
unsigned int pxm)
 if ( ret )
 goto destroy_m2p;
 
-if ( iommu_enabled && !iommu_passthrough && !need_iommu(hardware_domain) )
+if ( iommu_enabled && !iommu_hwdom_passthrough &&
+ !need_iommu(hardware_domain) )
 {
 for ( i = spfn; i < epfn; i++ )
 if ( iommu_map_page(hardware_domain, i, i, 
IOMMUF_readable|IOMMUF_writable) )
diff --git a/xen/drivers/passthrough/amd/iommu_init.c 
b/xen/drivers/passthrough/amd/iommu_init.c
index 474992a75a..15c10b0929 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1062,7 +1062,7 @@ static void __init amd_iommu_init_cleanup(void)
 radix_tree_destroy(_maps, xfree);
 
 iommu_enabled = 0;
-iommu_passthrough = 0;
+iommu_hwdom_passthrough = false;
 iommu_intremap = 0;
 iommuv2_enabled = 0;
 }
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 12d2695b89..ab39e7500d 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -121,7 +121,7 @@ static void amd_iommu_setup_domain_device(
 BUG_ON( !hd->arch.root_table || !hd->arch.paging_mode ||
 !iommu->dev_table.buffer );
 
-if ( iommu_passthrough && is_hardware_domain(domain) )
+if ( iommu_hwdom_passthrough && is_hardware_domain(domain) )
 valid = 0;
 
 if ( ats_enabled )
@@ -256,7 +256,7 @@ static void __hwdom_init amd_iommu_hwdom_init(struct domain 
*d)
 if ( allocate_domain_resources(dom_iommu(d)) )
 BUG();
 
-if ( !iommu_passthrough && !need_iommu(d) )
+if ( !iommu_hwdom_passthrough && !need_iommu(d) )
 {
 int rc = 0;
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 70d218f910..06b77eaa31 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -52,15 +52,16 @@ custom_param("iommu", parse_iommu_param);
 bool_t __initdata iommu_enable = 1;
 bool_t __read_mostly iommu_enabled;
 bool_t __read_mostly force_iommu;
-bool_t __hwdom_initdata iommu_dom0_strict;
 bool_t __read_mostly iommu_verbose;
 bool_t __read_mostly iommu_workaround_bios_bug;
 bool_t __read_mostly iommu_igfx = 1;
-bool_t __read_mostly iommu_passthrough;
 bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
 
+bool __hwdom_initdata iommu_hwdom_strict;
+bool __read_mostly iommu_hwdom_passthrough;
+
 /*
  * In the current implementation of VT-d posted interrupts, in some extreme
  * cases, the per cpu list which saves the blocked vCPU will be very long,
@@ -121,9 +122,9 @@ static int __init parse_iommu_param(const char *s)
 else if ( !strncmp(s, "amd-iommu-perdev-intremap", ss - s) )
 amd_iommu_perdev_intremap = val;
 else if ( !strncmp(s, "dom0-passthrough", ss - s) )
-iommu_passthrough = val;
+iommu_hwdom_passthrough = val;
 else if ( !strncmp(s, "dom0-strict", ss - s) )
-iommu_dom0_strict = val;
+iommu_hwdom_strict = val;
 else if ( !strncmp(s, "sharept", ss - s) )
 iommu_hap_pt_share = val;
 else
@@ -158,11 +159,11 @@ static void __hwdom_init check_hwdom_reqs(struct domain 
*d)
 
 arch_iommu_check_autotranslated_hwdom(d);
 
-if ( iommu_passthrough )
+if ( iommu_hwdom_passthrough )
 panic("Dom0 uses paging translated mode, dom0-passthrough must not be "
   "enabled\n");
 
-iommu_dom0_strict = 1;
+iommu_hwdom_strict = true;
 }
 
 void __hwdom_init iommu_hwdom_init(struct domain *d)
@@ -175,7 +176,7 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
 return;
 
 register_keyhandler('o', _dump_p2m_table, "dump iommu p2m table", 0);
-d->need_iommu = !!iommu_dom0_strict;
+d->need_iommu = !!iommu_hwdom_strict;
 if ( need_iommu(d) && 

Re: [Xen-devel] [PATCH v2 00/12] Improvements to domain creation

[Andrew Cooper]

On 14/08/18 14:12, Christian Lindig wrote:
>
> On 13/08/18 11:00, Andrew Cooper wrote:
>> This series can be found in git form here:
>>   
>> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-create-v1
> Is this the correct URL? The subject says v2 but this is branch v1.

Oops yes.

http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-create-v2
works as well, and is the intended URL.

>
> Looking over the OCaml-related patches, I think they are looking good.
> Since we would like all code to be safe-string compliant I checked
> that OCaml values of type string are not being mutated but I would
> like Andrew to confirm this.

There is no change to any string handling here.  The only string used
during the domaincreate hypercall is the UUID string, which is only read
by the stubs, not altered.

~Andrew

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

Re: [Xen-devel] [PATCH v2 00/12] Improvements to domain creation

[Christian Lindig]

On 13/08/18 11:00, Andrew Cooper wrote:

This series can be found in git form here:
   
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-create-v1

Is this the correct URL? The subject says v2 but this is branch v1.

Looking over the OCaml-related patches, I think they are looking good. 
Since we would like all code to be safe-string compliant I checked that 
OCaml values of type string are not being mutated but I would like 
Andrew to confirm this.


-- Christian

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

[Xen-devel] [linux-4.14 test] 125881: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 build-i386-pvops  6 kernel-build fail REGR. vs. 125175

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 125859

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 125175
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 125175
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125175

Tests which did not succeed, but are not blocking:
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 125175
 build-arm64-xsm   3 capture-logs  broken blocked in 125175
 build-arm64-pvops 3 capture-logs  broken blocked in 125175
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail in 125859 never pass
 test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 125859 never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail in 125859 never pass
 test-amd64-i386-libvirt 13 migrate-support-check fail in 125859 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail in 125859 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail in 125859 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail in 125859 never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail in 125859 never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail in 125859 never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail in 125859 never 
pass
 

[Xen-devel] [libvirt test] 125885: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Regressions which are regarded as allowable (not blocking):
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 123814
 build-arm64   2 hosts-allocate broken REGR. vs. 123814
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 123814
 build-arm64-xsm   3 capture-logs  broken blocked in 123814
 build-arm64-pvops 3 capture-logs  broken blocked in 123814

version targeted for testing:
 libvirt  0a476f152150f62306f9f8d124aa44e4adb9158c
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   70 days
Failing since123840  2018-06-06 04:19:28 Z   69 days   53 attempts
Testing same since   125864  2018-08-11 18:53:19 Z2 days2 attempts


People who touched revisions under test:
Ales Musil 
  Andrea Bolognani 
  Anya Harter 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Changkuo Shi 
  Chen Hanxiao 
  Christian Ehrhardt 
  Clementine Hayat 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Marek Marczykowski-Górecki 
  Martin Kletzander 
  Matthias Bolte 
  Michal Privoznik 
  Michal Prívozník 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shi Lei 
  Shichangkuo 
  Simon Kobyda 
  Stefan Bader 
  Stefan Berger 
  Sukrit Bhatnagar 
  Tomáš Golembiovský 
  w00251574 
  Weilun Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  

Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC

[Julien Grall]

Hi Amit,

On 07/08/18 18:07, Amit Singh Tomar wrote:

This patch adds driver for UART controller present on Amlogic S905 SoC.
https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf


The spec does not seems to provide the offset register. Where did you 
find them?




Signed-off-by: Amit Singh Tomar 
---
  xen/drivers/char/Kconfig  |   8 ++
  xen/drivers/char/Makefile |   1 +
  xen/drivers/char/meson-uart.c | 290 ++
  3 files changed, 299 insertions(+)
  create mode 100644 xen/drivers/char/meson-uart.c

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index cc78ec3..b9fee4e 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -20,6 +20,14 @@ config HAS_MVEBU
  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
  based board, say Y.
  
+config HAS_MESON

+bool
+default y
+depends on ARM_64
+help
+  This selects the Marvell MESON UART. If you have a Amlogic S905
+  based board, say Y.
+
  config HAS_PL011
bool
default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index b68c330..7c646d7 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
  obj-$(CONFIG_HAS_PL011) += pl011.o
  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_HAS_MESON) += meson-uart.o
  obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
diff --git a/xen/drivers/char/meson-uart.c b/xen/drivers/char/meson-uart.c
new file mode 100644
index 000..8fe7e62
--- /dev/null
+++ b/xen/drivers/char/meson-uart.c
@@ -0,0 +1,290 @@
+/*
+ * xen/drivers/char/meson-uart.c
+ *
+ * Driver for Amlogic MESON UART
+ *
+ * Copyright (c) 2018, Amit Singh Tomar .
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define UART_WFIFO  0x00
+#define UART_RFIFO  0x04
+#define UART_CONTROL0x08
+#define UART_STATUS 0x0c
+#define UART_MISC   0x10
+#define UART_REG5   0x14
+
+/* UART_CONTROL bits */
+#define UART_TX_EN  BIT(12)
+#define UART_RX_EN  BIT(13)
+#define UART_TX_RST BIT(22)
+#define UART_RX_RST BIT(23)
+#define UART_CLEAR_ERR  BIT(24)
+#define UART_RX_INT_EN  BIT(27)
+#define UART_TX_INT_EN  BIT(28)
+
+/* UART_STATUS bits */
+#define UART_PARITY_ERR BIT(16)
+#define UART_FRAME_ERR  BIT(17)
+#define UART_TX_FIFO_WERR   BIT(18)
+#define UART_RX_EMPTY   BIT(20)
+#define UART_TX_FULLBIT(21)
+#define UART_TX_EMPTY   BIT(22)
+#define UART_TX_CNT_MASKGENMASK(14, 8)
+
+
+#define UART_XMIT_IRQ_CNT_MASK  GENMASK(15, 8)
+#define UART_RECV_IRQ_CNT_MASK  GENMASK(7, 0)
+
+#define TX_FIFO_SIZE64
+
+static struct meson_s905_uart {
+unsigned int irq;
+void __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+} meson_s905_com = {0};


AFAIK, {0} is not necessary.


+
+#define meson_s905_read(uart, off)   readl((uart)->regs + off)
+#define meson_s905_write(uart, off, val) writel(val, (uart->regs) + off)


s/(uart->regs)/(uart)->regs/


+
+static void meson_s905_uart_interrupt(int irq, void *data,
+struct cpu_user_regs *regs)


The indentation looks wrong here.


+{
+struct serial_port *port = data;
+struct meson_s905_uart *uart = port->uart;
+uint32_t st = meson_s905_read(uart, UART_STATUS);
+
+if ( !(st & UART_RX_EMPTY) )
+{
+serial_rx_interrupt(port, regs);
+}
+
+if ( !(st & UART_TX_FULL) )
+{
+if ( st & UART_TX_INT_EN )
+serial_tx_interrupt(port, regs);
+}
+


NIT: No need for this newline.


+}
+
+static void __init meson_s905_uart_init_preirq(struct serial_port *port)
+{
+struct meson_s905_uart *uart = port->uart;
+uint32_t reg;
+
+reg = meson_s905_read(uart, UART_CONTROL);
+reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);


I am not sure why you are clearing those bits. AFAIU, init_preirq will 
reset the serials, so you 

[Xen-devel] [xen-4.7-testing test] 125879: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 
125057

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-credit2   7 xen-boot fail in 125858 pass in 125879
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125858 pass 
in 125879
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125858 pass 
in 125879
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 125858 pass 
in 125879
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
125708
 test-xtf-amd64-amd64-4   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 125858
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail 
pass in 125858
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 125858
 test-armhf-armhf-xl-arndale  19 leak-check/check   fail pass in 125858

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 125057
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 125057
 build-arm64   2 hosts-allocate broken REGR. vs. 125057

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 125057
 build-arm64   3 capture-logs  broken blocked in 125057
 build-arm64-xsm   3 capture-logs  broken blocked in 125057
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 125708 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 125708 never 
pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 125708 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 125708 never pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 125708 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 125708 never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 125708 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 125708 never 
pass
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125057
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125057
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125057
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125057
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125057
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125057
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125057
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125057
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125057
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125057
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 125057
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 125057
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125057
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 

Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support

[Julien Grall]

Hi Amit,

On 07/08/18 18:07, Amit Singh Tomar wrote:

Signed-off-by: Amit Singh Tomar 
---
  docs/misc/arm/early-printk.txt |  1 +
  xen/arch/arm/Rules.mk  |  1 +
  xen/arch/arm/arm64/debug-meson.inc | 50 ++
  3 files changed, 52 insertions(+)
  create mode 100644 xen/arch/arm/arm64/debug-meson.inc

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index f765f59..2aa9528 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -41,6 +41,7 @@ the name of the machine:
- juno: printk with pl011 on Juno platform
- lager: printk with SCIF0 on Renesas R-Car H2 processors
- midway: printk with the pl011 on Calxeda Midway processors
+  - meson: printk with the MESON for Amlogic S905 SoCs
- mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
- omap5432: printk with UART3 on TI OMAP5432 processors
- rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index f264592..d4fabdc 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
  EARLY_PRINTK_juno   := pl011,0x7ff8
  EARLY_PRINTK_lager  := scif,0xe6e6
  EARLY_PRINTK_midway := pl011,0xfff36000
+EARLY_PRINTK_meson  := meson,0xc81004c0


I would prefer if no new alias are added. The same could be achieved 
with CONFIG_EARLY_PRINTK=meson,0xc81004c0.


This could be documented on the wiki.

Cheers,


  EARLY_PRINTK_mvebu  := mvebu,0xd0012000
  EARLY_PRINTK_omap5432   := 8250,0x4802,2
  EARLY_PRINTK_rcar3  := scif,0xe6e88000
diff --git a/xen/arch/arm/arm64/debug-meson.inc 
b/xen/arch/arm/arm64/debug-meson.inc
new file mode 100644
index 000..d5507d3
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-meson.inc
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/arm64/debug-meson.inc
+ *
+ * MESON specific debug code.
+ *
+ * Copyright (c) 2018, Amit Singh Tomar .
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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 .
+ */
+
+#define UART_STATUS_REG 0x0c
+#define UART_TX_REG 0x00


I would prefer if we stick with the spec name. So UART_TX_REG should be 
renamed UART_WFIFO_REG.


Also, it might be worth considering to prefix them with AML_ so it is 
easy to find them on lookup.



+


Looking at the earlyconsole implementation in Linux, it seems that TX 
needs to be enabled first (see meson_uart_enable_tx_engine).


Is it now done in the firmware?


+/*
+ * MESON UART wait UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #UART_STATUS_REG] /* status register */
+tstw\c, #(1 << 21)  /* Check TXFIFO FULL bit */


Please define 1 << 21 rather than hardcoding it.


+b.ne   1b   /* Wait for the UART to be ready */
+.endm
+
+/*
+ * MESON UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+   strb  \wt, [\xb, #UART_TX_REG]
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */



Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 22ec06c8aaa1c4023bb7f960746da57f1b648568
baseline version:
 ovmf 1aa9314e3a84b27f74f239155fc0ec3f58b66be0

Last test of basis   125851  2018-08-10 20:10:59 Z3 days
Testing same since   125900  2018-08-14 01:10:52 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 
  chenc2 

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
   1aa9314e3a..22ec06c8aa  22ec06c8aaa1c4023bb7f960746da57f1b648568 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH 1/1] cameraif: add ABI for para-virtual camera

[Juergen Gross]

On 31/07/18 11:31, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> This is the ABI for the two halves of a para-virtualized
> camera driver which extends Xen's reach multimedia capabilities even
> farther enabling it for video conferencing, In-Vehicle Infotainment,
> high definition maps etc.
> 
> The initial goal is to support most needed functionality with the
> final idea to make it possible to extend the protocol if need be:
> 
> 1. Provide means for base virtual device configuration:
>  - pixel formats
>  - resolutions
>  - frame rates
> 2. Support basic camera controls:
>  - contrast
>  - brightness
>  - hue
>  - saturation
> 3. Support streaming control
> 4. Support zero-copying use-cases
> 
> Signed-off-by: Oleksandr Andrushchenko 

Some style issues below...

> ---
>  xen/include/public/io/cameraif.h | 981 +++
>  1 file changed, 981 insertions(+)
>  create mode 100644 xen/include/public/io/cameraif.h
> 
> diff --git a/xen/include/public/io/cameraif.h 
> b/xen/include/public/io/cameraif.h
> new file mode 100644
> index ..bdc6a1262fcf
> --- /dev/null
> +++ b/xen/include/public/io/cameraif.h

> +struct xencamera_config {
> +uint32_t pixel_format;
> +uint32_t width;
> +uint32_t height;
> +uint32_t frame_rate_nom;
> +uint32_t frame_rate_denom;
> +uint8_t num_bufs;

Add explicit padding?

> +};

> +struct xencamera_req {
> +uint16_t id;
> +uint8_t operation;
> +uint8_t reserved[5];
> +union {
> +struct xencamera_config config;
> +struct xencamera_buf_create_req buf_create;
> + struct xencamera_buf_destroy_req buf_destroy;
> + struct xencamera_set_ctrl_req set_ctrl;

No tabs, please.

> +uint8_t reserved[56];
> +} req;
> +};
> +
> +struct xencamera_resp {
> +uint16_t id;
> +uint8_t operation;
> +uint8_t reserved;
> +int32_t status;
> +union {
> +struct xencamera_config config;
> +struct xencamera_buf_details_resp buf_details;
> + struct xencamera_get_ctrl_details_resp ctrl_details;

Tab again.

> +uint8_t reserved1[56];
> +} resp;
> +};


Juergen

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

Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC - Agenda items

[Sergey Dyasli]

On Mon, 2018-08-13 at 02:54 -0600, Jan Beulich wrote:
> > > > On 13.08.18 at 09:46,  wrote:
> > 
> > proposed topics so far:
> > * 4.10+ changes to Xen's memory scrubbing: discussion of the changes 
> > that made to it in recent versions of Xen (4.10+) - Christopher
> > * Project Management stuff to keep the Momentum going - primarily 
> > looking for Intel updates
> 
> Timing is not really good for this, but deferring to the next meeting is
> also too long. I realize everyone's quite busy, and I'm myself also
> struggling to get to look at
> - VMX MSRs policy for Nested Virt: part 1 (I've looked over this, and I
>   think it's okay, but I also think that in particular nested stuff wants
>   both maintainers and Andrew to look over)

Regarding VMX MSRs, I plan to refresh the series once the new CPUID+MSR
infrastructure is in place. This will allow to configure VMX features
for each guest independently.

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

Re: [Xen-devel] [PATCH] libs/foreignmemory: Avoid printing an error for ENOTSUPP

[Wei Liu]

On Mon, Aug 13, 2018 at 06:33:25PM +0100, Julien Grall wrote:
> Resource mapping is not supported on Arm and results to an error message
> at every guest boot:
> 
> xenforeignmemory: error: ioctl failed: Operation not supported
> 
> Hide the error message when errnor is ENOTSUPP.
> 
> Signed-off-by: Julien Grall 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] libs/foreignmemory: Avoid printing an error for ENOTSUPP

[Paul Durrant]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 13 August 2018 18:33
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ;
> Paul Durrant ; Julien Grall 
> Subject: [PATCH] libs/foreignmemory: Avoid printing an error for ENOTSUPP
> 
> Resource mapping is not supported on Arm and results to an error message
> at every guest boot:
> 
> xenforeignmemory: error: ioctl failed: Operation not supported
> 
> Hide the error message when errnor is ENOTSUPP.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Paul Durrant 

> ---
>  tools/libs/foreignmemory/linux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libs/foreignmemory/linux.c
> b/tools/libs/foreignmemory/linux.c
> index a6b41b0b7f..3686cf41e0 100644
> --- a/tools/libs/foreignmemory/linux.c
> +++ b/tools/libs/foreignmemory/linux.c
> @@ -307,7 +307,7 @@ int osdep_xenforeignmemory_map_resource(
>  {
>  int saved_errno;
> 
> -if ( errno != ENOTTY )
> +if ( errno != ENOTTY && errno != EOPNOTSUPP )
>  PERROR("ioctl failed");
>  else
>  errno = EOPNOTSUPP;
> --
> 2.11.0


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

Re: [Xen-devel] Xen ballooning interface

[Juergen Gross]

On 14/08/18 09:34, Jan Beulich wrote:
 On 14.08.18 at 09:19,  wrote:
>> On 14/08/18 09:02, Jan Beulich wrote:
>> On 13.08.18 at 17:44,  wrote:
 On 13/08/18 17:29, Jan Beulich wrote:
 On 13.08.18 at 16:20,  wrote:
>> On 13/08/18 15:54, Jan Beulich wrote:
>> On 13.08.18 at 15:06,  wrote:
 Suggested new interface
 ---
 Hypercalls, memory map(s) and ACPI tables should stay the same (for
 compatibility reasons or because they are architectural interfaces).

 As the main confusion in the current interface is related to the
 specification of the target memory size this part of the interface
 should be changed: specifying the size of the ballooned area instead
 is much clearer and will be the same for all guest types (no firmware
 memory or magic additions involved).
>>>
>>> But isn't this backwards? The balloon size is a piece of information
>>> internal to the guest. Why should the outside world know or care?
>>
>> Instead of specifying an absolute value to reach you'd specify how much
>> memory the guest should stay below its maximum. I think this is a valid
>> approach.
>
> But with you vNUMA model there's no single such value, and nothing
> like a "maximum" (which would need to be per virtual node afaics).

 With vNUMA there is a current value of memory per node supplied by the
 tools and a maximum per node can be caclulated the same way.
>>>
>>> Can it? If so, I must be overlooking some accounting done
>>> somewhere. I'm only aware of a global maximum.
>>
>> The tools set the vnuma information for the guest. How do they do this
>> without knowing the memory size per vnuma node?
> 
> That's the current (initial) size, not the maximum.

Which is the same in the current implementation:
libxl__vnuma_config_check() will fail if the memory of all vnuma nodes
won't sum up to the max memory of the domain.


Juergen

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

Re: [Xen-devel] Xen ballooning interface

[Jan Beulich]

>>> On 14.08.18 at 09:19,  wrote:
> On 14/08/18 09:02, Jan Beulich wrote:
> On 13.08.18 at 17:44,  wrote:
>>> On 13/08/18 17:29, Jan Beulich wrote:
>>> On 13.08.18 at 16:20,  wrote:
> On 13/08/18 15:54, Jan Beulich wrote:
> On 13.08.18 at 15:06,  wrote:
>>> Suggested new interface
>>> ---
>>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>>> compatibility reasons or because they are architectural interfaces).
>>>
>>> As the main confusion in the current interface is related to the
>>> specification of the target memory size this part of the interface
>>> should be changed: specifying the size of the ballooned area instead
>>> is much clearer and will be the same for all guest types (no firmware
>>> memory or magic additions involved).
>>
>> But isn't this backwards? The balloon size is a piece of information
>> internal to the guest. Why should the outside world know or care?
>
> Instead of specifying an absolute value to reach you'd specify how much
> memory the guest should stay below its maximum. I think this is a valid
> approach.

 But with you vNUMA model there's no single such value, and nothing
 like a "maximum" (which would need to be per virtual node afaics).
>>>
>>> With vNUMA there is a current value of memory per node supplied by the
>>> tools and a maximum per node can be caclulated the same way.
>> 
>> Can it? If so, I must be overlooking some accounting done
>> somewhere. I'm only aware of a global maximum.
> 
> The tools set the vnuma information for the guest. How do they do this
> without knowing the memory size per vnuma node?

That's the current (initial) size, not the maximum.

Jan



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

Re: [Xen-devel] Emulation and active (valid) interrupts

[Jan Beulich]

>>> On 13.08.18 at 21:17,  wrote:
> On 8/13/18 4:45 PM, Razvan Cojocaru wrote:
>> On 8/13/18 4:38 PM, Jan Beulich wrote:
>> On 13.08.18 at 15:19,  wrote:
 On 8/13/18 3:58 PM, Jan Beulich wrote:
 On 13.08.18 at 14:51,  wrote:
>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>> ran first and then an interrupt popped up, or if an interrupt had
>> already been __vmwrit()ten and then CLI caused the invalid guest state.
>
> I'd expect it to be the latter - an external interrupt presumably
> can't be injected when EFLAGS.IF is clear. Why are we emulating
> CLI in the first place? With a pending external interrupt, shouldn't
> we just exit back to guest context without emulating anything?

 In this particular case we're emulating CLI because the vm_event
 response requests it.

 Tamas' test marks all of the guest's pages XENMEM_access_x, and at some
 point a vm_event arrives somewhere in a page where CLI is read from,
 AFAICT. Doing nothing would get us into an infinite loop, and since we
 don't want to mark the page rwx, we try to emulate CLI.
>>>
>>> Doing nothing would get you into an infinite loop only if at each
>>> attempt there's yet again an event to be re-injected. Of course
>>> the risk of this grows the longer it takes to processes things in
>>> your tool, but if there is an event to be re-injected then I don't
>>> see what else you can do. Trying to ditch the event would
>>> certainly be the wrong thing. I suggest you try to get advice
>>> from the VMX maintainers - perhaps I'm simply overlooking an
>>> obvious route out of the state you're apparently in.
>> 
>> [Missed hitting "Reply all" - sorry, and re-sent. Also, added Jun and
>> Kevin to the conversation.]
>> 
>> You're of course right, what I meant to say was that if we don't
>> emulate, don't mark the page rwx, and don't move RIP we'll be in an
>> infinite loop of read-caused vm_event -> userspace tool gets event ->
>> does nothing, but responds to it -> guest resumes at the same RIP
>> (pointing, in this case at CLI, but it could be anything) -> goto begin.
>> 
>> We need to do something to keep the guest going, and the generic way to
>> accomplish this is to ask Xen to emulate whatever instruction is at RIP
>> (because the Xen emulator, at least for the time being, ignores EPT
>> restrictions).
> 
> On top of everything, there's also a basic design problem: the way the
> code is written now:
> 
> 1. The "inject events" code seems to be advertised as living in intr.c -
> but here's an exception to the rule with vmx_idtv_reinject() living in
> vmx.c.

But "re-inject" != "inject".

> 2. The single-step code implies that once we have vmx_intr_assist()
> return, event injection is blocked:
> 
> 234 /* Block event injection when single step with MTF. */
> 235 if ( unlikely(v->arch.hvm_vcpu.single_step) )
> 236 {
> 237 v->arch.hvm_vmx.exec_control |= CPU_BASED_MONITOR_TRAP_FLAG;
> 238 vmx_update_cpu_exec_control(v);
> 239 return;
> 240 }
> 
> an assumption that has turned out to be false.

As far as I'm aware it is well known that MTF handling isn't the
greatest.

> 3. Obviously the idea of injecting something just before taking an exit,
> for example caused by EXIT_REASON_EPT_VIOLATION is not natural to us.

Indeed, yet so far I've not seen a summary of all the conditions
under which you see this happening. Remember that an EPT
violation with valid IDT vectoring information means the violation
has occurred _while_ delivering an event. It is my understanding
that this can only occur if the EPT violation happens for an IDT,
GDT, TSS, or stack access. In particular the instruction pointed
at does not matter here at all.

I therefore wonder whether either you're removing permissions
too aggressively, or whether the state information passed to the
tools side handling code of the VM event is insufficient to
recognize that instruction emulation must not be attempted, and
instead actions need to be taken to make it possible for the
pending event to be delivered without incurring another EPT
violation. Note that single stepping is as little of an option as
insn emulation in this case. If anything, the event delivery
would need emulating (for which there is no code at all in the
hypervisor, iirc).

> Furthermore, the way the code is written now, _first_ we call
> vmx_idtv_reinject() and only then do we handle EXIT_REASON_EPT_VIOLATION

I'm afraid if this was done in the opposite order, nothing would
change for you: The to-be-re-injected event would still need
re-injecting, and hence you still couldn't inject an event of your
liking (or allow e.g. CLI to be emulated).

Jan


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

Re: [Xen-devel] Xen ballooning interface

[Juergen Gross]

On 14/08/18 09:02, Jan Beulich wrote:
 On 13.08.18 at 17:44,  wrote:
>> On 13/08/18 17:29, Jan Beulich wrote:
>> On 13.08.18 at 16:20,  wrote:
 On 13/08/18 15:54, Jan Beulich wrote:
 On 13.08.18 at 15:06,  wrote:
>> Suggested new interface
>> ---
>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>> compatibility reasons or because they are architectural interfaces).
>>
>> As the main confusion in the current interface is related to the
>> specification of the target memory size this part of the interface
>> should be changed: specifying the size of the ballooned area instead
>> is much clearer and will be the same for all guest types (no firmware
>> memory or magic additions involved).
>
> But isn't this backwards? The balloon size is a piece of information
> internal to the guest. Why should the outside world know or care?

 Instead of specifying an absolute value to reach you'd specify how much
 memory the guest should stay below its maximum. I think this is a valid
 approach.
>>>
>>> But with you vNUMA model there's no single such value, and nothing
>>> like a "maximum" (which would need to be per virtual node afaics).
>>
>> With vNUMA there is a current value of memory per node supplied by the
>> tools and a maximum per node can be caclulated the same way.
> 
> Can it? If so, I must be overlooking some accounting done
> somewhere. I'm only aware of a global maximum.

The tools set the vnuma information for the guest. How do they do this
without knowing the memory size per vnuma node?

> 
>> This results in a balloon size per node.
>>
>> There is still the option to let the guest adjust the per node balloon
>> sizes after reaching the final memory size or maybe during the process
>> of ballooning at a certain rate.
> 
> I'm probably increasingly confused: Shouldn't, for whichever value
> in xenstore, there be a firm determination of which single party is
> supposed to modify a value? Aiui the intention is for the (target)
> balloon size to be set by the tools.

Sorry if I wasn't clear enough here: the guest shouldn't rewrite the
target balloon size, but e.g. memory/vnode/balloon-size.

> 
>> Any further thoughts on this?
>
> The other problem we've always had was that address information
> could not be conveyed to the driver. The worst example in the past
> was that 32-bit PV domains can't run on arbitrarily high underlying
> physical addresses, but of course there are other cases where
> memory below a certain boundary may be needed. The obvious
> problem with directly exposing address information through the
> interface is that for HVM guests machine addresses are meaningless.
> Hence I wonder whether a dedicated "balloon out this page if you
> can" mechanism would be something to consider.

 Isn't this a problem orthogonal to the one we are discussing here?
>>>
>>> Yes, but I think we shouldn't design a new interface without
>>> considering all current shortcomings.
>>
>> I don't think the suggested interface would make it harder to add a way
>> to request special pages to be preferred in the ballooning process.
> 
> Address and (virtual) node may conflict with one another. But I
> think we've meanwhile settled on the node value to only be a hint
> in a request.

I think so, yes.


Juergen


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

Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC - Agenda items

[Lars Kurth]

Revised Agenda:
* 4.10+ changes to Xen's memory scrubbing: discussion of the changes 
   that made to it in recent versions of Xen (4.10+) - Christopher
* I think we need to talk about how we mean to unblock
   large chunks of work - Jan (see example list below)
* Project Management stuff to keep the Momentum going 
   (primarily requires Intel input)
* AOB

On 13/08/2018, 09:54, "Jan Beulich"  wrote:

>>> On 13.08.18 at 09:46,  wrote:
> proposed topics so far:
> * 4.10+ changes to Xen's memory scrubbing: discussion of the changes 
> that made to it in recent versions of Xen (4.10+) - Christopher
> * Project Management stuff to keep the Momentum going - primarily 
> looking for Intel updates

Timing is not really good for this, but deferring to the next meeting is
also too long. I realize everyone's quite busy, and I'm myself also
struggling to get to look at
- VMX MSRs policy for Nested Virt: part 1 (I've looked over this, and I
  think it's okay, but I also think that in particular nested stuff wants
  both maintainers and Andrew to look over)
- vpci: add support for SR-IOV capability
- paravirtual IOMMU interface
- x86/domctl: Save info for one vcpu instance
- SSBD AMD via LS CFG Enablement
and not to speak of "add vIOMMU support with irq remapping function
of virtual VT-d". I'm however myself as well in an increasingly awkward
position to do / post further work, due to there being patch series
stalled in part from long before the 4.11 freeze (listing only series here,
there are also individual stalled patches):
- x86: improve PDX <-> PFN and alike translations
- x86: assorted assembly related cleanup
- x86: indirect call overhead reduction
- x86/HVM: implement memory read caching
- x86: more power-efficient CPU parking
And I'm not even daring to guess what is going to happen to the AVX512
patches that I have in the works for the emulator.

Bottom line - I think we need to talk about how we mean to unblock
large chunks of work.

Jan




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