Re: [Xen-devel] [PATCH v10] VT-d: use correct BDF for VF to search VT-d unit

> From: Gao, Chao > Sent: Monday, August 28, 2017 10:42 AM > > When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' > are under the scope of the same VT-d unit as the 'Physical Function'. > A 'Physical Function' can be a 'Traditional Function' or an ARI > 'Extended Function'. And

Re: [Xen-devel] [PATCH RESEND v9] VT-d: use correct BDF for VF to search VT-d unit

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, August 25, 2017 11:20 PM > > > > Currently, VF won't implement SRIOV feature, seeing > > SRIOV specv1.1 chapter 3.7 PCI Express Extended Capabilities. Even VF > > will implement SRIOV later, I think as long as a function is SRIOV >

Re: [Xen-devel] [PATCH v8 00/13] Unify the interrupt delivery mode and do its setup in advance

Hi, Follow Juergen's advice, +CC xen-devel and linux-acpi In case a single patch of a series isn't stand alone it would be nice to receive at least the cover letter of the series in order to know what its all about. Thanks, dou. At 08/28/2017 11:20 AM, Dou Liyang wrote: Changes V7

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, Today's linux-next merge of the xen-tip tree got conflicts in: arch/x86/xen/xen-asm.S arch/x86/xen/xen-asm_64.S between commit: edcb5cf84f05 ("x86/paravirt/xen: Remove xen_patch()") from the tip tree and commits: ad5b8c4ba323("xen: get rid of paravirt op

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

Hi Juergen, At 08/28/2017 12:32 PM, Juergen Gross wrote: On 28/08/17 06:25, Juergen Gross wrote: On 28/08/17 05:20, Dou Liyang wrote: XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus().

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

On 28/08/17 06:25, Juergen Gross wrote: > On 28/08/17 05:20, Dou Liyang wrote: >> XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() >> initializes interrupts in the XEN PV specific way and does not invoke >> native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is >>

Re: [Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

On 28/08/17 05:20, Dou Liyang wrote: > XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() > initializes interrupts in the XEN PV specific way and does not invoke > native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is > not invoked either. > > The invocation of

[Xen-devel] [PATCH v10] VT-d: use correct BDF for VF to search VT-d unit

When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under the scope of the same VT-d unit as the 'Physical Function'. A 'Physical Function' can be a 'Traditional Function' or an ARI 'Extended Function'. And furthermore, 'Extended Functions' on an endpoint are under the scope

[Xen-devel] [PATCH v8 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system

XEN PV overrides smp_prepare_cpus(). xen_pv_smp_prepare_cpus() initializes interrupts in the XEN PV specific way and does not invoke native_smp_prepare_cpus(). As a consequence, x86_init.intr_mode_init() is not invoked either. The invocation of x86_init.intr_mode_init() will be moved from

[Xen-devel] [linux-linus test] 112895: regressions - trouble: blocked/broken/fail/pass

flight 112895 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112895/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 112891 Regressions which

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:31, Peter Zijlstra wrote: > On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote: >> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > >>> Have you considered a kernel with -mcmodel=small (or medium) instead of >>> -fpie >>> -mcmodel=large? We can

[Xen-devel] [linux-3.18 test] 112894: trouble: blocked/broken/fail/pass

flight 112894 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112894/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

On Fri, Aug 25, 2017 at 11:38 AM, Christopher Lameter wrote: > > > On Thu, 17 Aug 2017, Boris Lukashev wrote: > >> Is the expectation then to have security functions also decrease size >> and operational latency? Seems a bit unrealistic if so. >> 1-2% performance hit on systems

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

flight 112893 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112893/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 112809

[Xen-devel] [linux-linus test] 112891: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 112891 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112891/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112887 pass in 112891

[Xen-devel] [linux-3.18 test] 112889: trouble: blocked/broken/fail/pass

flight 112889 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112889/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

[Xen-devel] [libvirt test] 112890: tolerable trouble: blocked/broken/pass - PUSHED

flight 112890 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112890/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1

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

flight 112888 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112888/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112809

[Xen-devel] [xen-unstable-coverity test] 112892: all pass - PUSHED

flight 112892 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/112892/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 803c5a2a42e7c72a4c848e0f0106a941b758a91f baseline version: xen

[Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

The original dummy xsm_map_gmfn_foregin checks if source domain has the proper privileges over the target domain. Under this policy, it's not allowed if a Dom0 wants to map pages from one DomU to another, which restricts some useful yet not dangerous use cases of the API, such as sharing pages

[Xen-devel] [PATCH v2 2/6] libxl: introduce a new structure to represent static shared memory regions

Add a new structure to the IDL familiy to represent static shared memory regions as proposed in the proposal "Allow setting up shared memory areas between VMs from xl config file" (see [1]). Also fix some code style issues (indentation, trailling whitespaces). [1]

[Xen-devel] [PATCH v2 1/6] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

This is for the proposal "Allow setting up shared memory areas between VMs from xl config file". See: https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from one domU to another and use

[Xen-devel] [PATCH v2 0/6] Allow setting up shared memory areas between VMs from xl config files

This series implements the new xl config entry proposed in [1]. Users can use the new config entry to statically setup shared memory areas among VMs that don't have grant table support so that they could communicate with each other through the static shared memory areas. [1] Proposla to allow

[Xen-devel] [PATCH v2 6/6] libxl: support unmapping static shared memory areas during domain destruction

Add libxl__sshm_del to unmap static shared memory areas mapped by libxl__sshm_add during domain creation. The unmapping process is: * For a master: decrease the refcount of the sshm region, if the refcount reaches 0, cleanup the whole sshm path. * For a slave: unmap the shared pages, and

[Xen-devel] [PATCH v2 3/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

Add the parsing utils for the newly introduced libxl_static_sshm struct to the libxl/libxlu_* family. And add realated parsing code in xl to parse the struct from xl config files. This is for the proposal "Allow setting up shared memory areas between VMs from xl config file" (see [1]). [1]

[Xen-devel] [PATCH v2 5/6] libxl: support mapping static shared memory areas during domain creation

Add libxl__sshm_add to map shared pages from one DomU to another, The mapping process involves the follwing steps: * Set defaults and check for further errors in the static_shm configs: overlapping areas, invalid ranges, duplicated master domain, no master domain etc. * Write

[Xen-devel] [linux-linus test] 112887: regressions - trouble: blocked/broken/fail/pass

flight 112887 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112887/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112876

[Xen-devel] [RFC v5]Proposal to Allow Setting up Shared Memory Areas between VMs from xl Config File

Hi, I'm updating this document to reflect some changes in the code based on the discussions on #xen-devel and on the mailing list. The biggest change is to ref-counting the sshm xenstore entry to avoid removing the node too early while the memory pages are still in use, in section 2.2. The rest