[Xen-devel] [PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window

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

flight 107736 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107736/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 107636 build-arm64-xsm

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

flight 107750 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107750/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 27/04/17 00:04, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote: >> I'm not feeling strong about it. So if you want to test for >> X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine >> with it. >> >> Will send V2 with that change. > > And

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

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

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

flight 107746 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107746/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH] dom_ids array implementation.

On 17-04-26 04:04:15, Jan Beulich wrote: > >>> On 20.04.17 at 07:38, wrote: > > --- a/xen/arch/x86/psr.c > > +++ b/xen/arch/x86/psr.c > > @@ -125,6 +125,8 @@ struct feat_node { > > uint32_t cos_reg_val[MAX_COS_REG_CNT]; > > }; > > > > +#define PSR_DOM_IDS_NUM

Re: [Xen-devel] vTPM: update email address and file path in MAINTAINERS file

BTW, I tried to clean up the vtpm code and stored it in the Git repo: https://github.com/virt2x/vtpm2vtpmmgr I hope that others will continue to clean up code and verify it (I don't have tpm1.2/ tpm2.0 machine to verified it).. Quan On April 27, 2017 10:28 AM, Quan Xu wrote: >From

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

flight 107743 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107743/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

[Xen-devel] vTPM: update email address and file path in MAINTAINERS file

>From 291938c64ccf3a6d580dad7d3ca3311a49a4572e Mon Sep 17 00:00:00 2001 From: Quan Xu Date: Fri, 28 Apr 2017 02:14:29 +0800 Subject: [PATCH] vTPM: update email address and file path in MAINTAINERS file Signed-off-by: Quan Xu --- MAINTAINERS | 4 ++-- 1

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

flight 107738 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107738/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] xen_exit_mmap() questions

On Wed, Apr 26, 2017 at 5:55 PM, Boris Ostrovsky wrote: > > > On 04/26/2017 06:49 PM, Andy Lutomirski wrote: >> >> On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky >> wrote: >>> >>> On 04/26/2017 04:52 PM, Andy Lutomirski wrote: I

Re: [Xen-devel] xen_exit_mmap() questions

On 04/26/2017 06:49 PM, Andy Lutomirski wrote: On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky wrote: On 04/26/2017 04:52 PM, Andy Lutomirski wrote: I was trying to understand xen_drop_mm_ref() to update it for some changes I'm working on, and I'm wondering

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

flight 107734 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107734/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

[Xen-devel] [qemu-mainline test] 107686: regressions - trouble: broken/fail/pass

flight 107686 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107686/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 107636

Re: [Xen-devel] xen_exit_mmap() questions

On Wed, Apr 26, 2017 at 3:45 PM, Boris Ostrovsky wrote: > On 04/26/2017 04:52 PM, Andy Lutomirski wrote: >> I was trying to understand xen_drop_mm_ref() to update it for some >> changes I'm working on, and I'm wondering whether we need >> xen_exit_mmap() at all. >> >>

Re: [Xen-devel] xen_exit_mmap() questions

On 04/26/2017 04:52 PM, Andy Lutomirski wrote: > I was trying to understand xen_drop_mm_ref() to update it for some > changes I'm working on, and I'm wondering whether we need > xen_exit_mmap() at all. > > AFAICS the intent is to force all CPUs to drop their lazy uses of the > mm being destroyed

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

flight 107730 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

[Xen-devel] [seabios bisection] complete build-i386-xsm

branch xen-unstable xenbranch xen-unstable job build-i386-xsm testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://git.seabios.org/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote: > I'm not feeling strong about it. So if you want to test for > X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine > with it. > > Will send V2 with that change. And remove the corresponding clear_cpu_bug(c,

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Hi Julien, On 25 April 2017 at 14:43, Julien Grall wrote: >> We will also need another type of application: one which is >> periodically called by XEN itself, not actually servicing any domain >> request. This is needed for a >> coprocessor sharing framework

[Xen-devel] xen_exit_mmap() questions

I was trying to understand xen_drop_mm_ref() to update it for some changes I'm working on, and I'm wondering whether we need xen_exit_mmap() at all. AFAICS the intent is to force all CPUs to drop their lazy uses of the mm being destroyed so it can be unpinned before tearing down the page tables,

[Xen-devel] [ovmf baseline-only test] 71235: all pass

This run is configured for baseline tests only. flight 71235 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71235/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 227fe49d5d4fe6513fc09766f1c9f3ff330ea845 baseline

[Xen-devel] [libvirt test] 107696: regressions - FAIL

flight 107696 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107696/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 5 libvirt-buildfail REGR. vs. 107640 build-i386-libvirt

[Xen-devel] [xen-unstable test] 107676: tolerable FAIL - PUSHED

flight 107676 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107676/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107642 test-amd64-i386-xl-qemuu-win7-amd64

[Xen-devel] [xtf test] 107724: all pass - PUSHED

flight 107724 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107724/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 7e7c4526bc137999335b6e8e4b3db233ae2cf4b9 baseline version: xtf

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

flight 107725 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107725/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

On 04/26/2017 02:19 PM, Andrew Cooper wrote: On 26/04/17 19:11, Mohit Gambhir wrote: Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General Protection Fault and thus results in a hypervisor crash. This patch fixes the crash by masking PC bit and returning an error in case

[Xen-devel] [PATCH v2] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 26/04/17 08:35, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 06:45:42AM +0200, Juergen Gross wrote: >> The really clean solution would be to add this test to set_cpu_bug() > > No, the really clean solution is to set it once and not play toggle > games. > >> This would work. OTOH I'd

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

flight 107718 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107718/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

On 26/04/17 19:11, Mohit Gambhir wrote: > Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General > Protection Fault and thus results in a hypervisor crash. This patch fixes the > crash by masking PC bit and returning an error in case any guest tries to > write > to it. > >

[Xen-devel] [PATCH v2] x86/vpmu_intel: Fix hypervisor crash by masking PC bit in MSR_P6_EVNTSEL

Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General Protection Fault and thus results in a hypervisor crash. This patch fixes the crash by masking PC bit and returning an error in case any guest tries to write to it. Signed-off-by: Mohit Gambhir ---

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

flight 107716 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107716/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 227fe49d5d4fe6513fc09766f1c9f3ff330ea845 baseline version: ovmf

[Xen-devel] [xen-unstable-smoke test] 107720: tolerable trouble: broken/pass - PUSHED

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

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Wed, 26 Apr 2017, Catalin Marinas wrote: > On Wed, Apr 26, 2017 at 10:00:30AM -0700, Stefano Stabellini wrote: > > On Wed, 26 Apr 2017, Catalin Marinas wrote: > > > On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote: > > > > On Tue, 25 Apr 2017, Julien Grall wrote: > > > > > On

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Wed, Apr 26, 2017 at 10:00:30AM -0700, Stefano Stabellini wrote: > On Wed, 26 Apr 2017, Catalin Marinas wrote: > > On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote: > > > On Tue, 25 Apr 2017, Julien Grall wrote: > > > > On 24/04/17 20:16, Stefano Stabellini wrote: > > > > >

Re: [Xen-devel] Enabling VT-d PI by default

On 18/04/17 07:24, Tian, Kevin wrote: >> From: Gao, Chao >> Sent: Monday, April 17, 2017 4:14 AM >> >> On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote: >> On 11.04.17 at 02:59, wrote: As you know, with VT-d PI enabled, hardware can directly deliver

Re: [Xen-devel] [PATCH 00/10] pl011 emulation support in Xen

On Wed, 26 Apr 2017, Bhupinder Thakur wrote: > Hi Julien, > > > >> tools/console/client/main.c | 6 + > >> tools/console/daemon/io.c| 532 > >> +++ > >> tools/libxc/include/xc_dom.h | 3 + > >> tools/libxc/xc_dom_arm.c | 7 +- >

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

On Wed, 26 Apr 2017, Julien Grall wrote: > Hi Bhupinder, > > On 26/04/2017 08:49, Bhupinder Thakur wrote: > > > > > Regarding the optimization you introduced in this patch, delaying > > > > > write > > > > > notifications until we receive a notification from xenconsoled, how > > > > > many > > >

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Wed, 26 Apr 2017, Catalin Marinas wrote: > On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote: > > On Tue, 25 Apr 2017, Julien Grall wrote: > > > On 24/04/17 20:16, Stefano Stabellini wrote: > > > > Given the outstanding regression we need to fix as soon as possible, > > > >

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

On 26/04/17 01:52, Chao Gao wrote: > VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU > running on the pCPU. Theoretically, there are 32K domain on single > host, 128 vCPUs per domain. If all vCPUs are blocked on the same pCPU, > 4M vCPUs are in the same list. Travelling this

[Xen-devel] [PATCH for-next v3 11/12] x86/pv/domain: clean up setup_compat_l4

Move updating type_info after clearing the page. Add spaces. Signed-off-by: Wei Liu --- xen/arch/x86/pv/domain.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index 8f6c6c5dec..a01e3516ca 100644

[Xen-devel] [PATCH for-next v3 10/12] x86/domain: move HVM specific code to hvm/domain.c

There is only one function arch_set_info_hvm_guest is moved. The check_segment function is also moved since arch_set_info_hvm_guest is the only user. No functional change. Signed-off-by: Wei Liu Acked-by: Jan Beulich Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH for-next v3 12/12] x86/pv/domain: clean up switch_compat

Remove the redundant is_pv_domain check. Rearrange setup_compat calls. Signed-off-by: Wei Liu --- xen/arch/x86/pv/domain.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index

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

flight 107662 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/107662/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358 Tests which are

Re: [Xen-devel] superpages lost after migration of HVM domU

On 26/04/17 16:43, Olaf Hering wrote: > On Thu, Apr 20, Jan Beulich wrote: > > On 20.04.17 at 18:04, wrote: >>> On Thu, Apr 20, Andrew Cooper wrote: >>> As it currently stands, the sending side iterates from 0 to p2m_size, and sends every frame on the first pass.

[Xen-devel] [PATCH for-next v3 05/12] x86/domain: factor out pv_vcpu_initialise

Move PV specific vcpu initialisation code to said function, but leave the only line needed by idle domain in vcpu_initialise. Use pv_vcpu_destroy in error path to simplify code. It is safe to do so because the destruction function accepts partially initialised vcpu struct. Signed-off-by: Wei Liu

[Xen-devel] [PATCH for-next v3 08/12] x86/domain: factor out pv_domain_initialise

Lump everything PV related in arch_domain_create into pv_domain_initialise. Though domcr_flags and config are not necessary, the new function is given those to match hvm counterpart. Since it cleans up after itself there is no need to clean up in arch_domain_create in case of failure. Remove the

[Xen-devel] [PATCH for-next v3 03/12] x86/domain: make release_compact_l4 NULL tolerant

Push the check in caller down to that function so that it becomes idempotent. No functional change. Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper --- Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH for-next v3 01/12] x86/mm: make free_perdomain_mappings idempotent

Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper --- Cc: Tim Deegan Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/mm.c | 8

[Xen-devel] [PATCH for-next v3 04/12] x86/domain: factor out pv_vcpu_destroy

The function is made idempotent on purpose. Note that free_compact_l4, release_compact_l4 and pv_destroy_gdt_ldt_l1tab are idempotent already. No functional change. Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper --- v3: update commit message

[Xen-devel] [PATCH for-next v3 02/12] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

This patch encapsulates the perdomain creation and destruction into helper functions and use them where appropriate. Since destroy_perdomain_mapping is idempotent, it is safe to call the destruction function multiple times. Signed-off-by: Wei Liu --- v2: new v3: use 1U and

[Xen-devel] [PATCH for-next v3 09/12] x86/domain: move PV specific code to pv/domain.c

Move all the PV specific code along with the supporting code to pv/domain.c. This in turn requires exporting a few functions in header files. Create pv/domain.h for that. Move paravirt_ctxt_switch_{from,to} declarations to domain.h. No functional change. Signed-off-by: Wei Liu

[Xen-devel] [PATCH for-next v3 06/12] x86/domain: push some code down to hvm_domain_initialise

We want to have a single entry point to initialise hvm guest. To do this, the setting of hap_enabled and creation of the per domain mappings is deferred, but that's not a problem. No functional change. Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH for-next v3 07/12] x86/domain: factor out pv_domain_destroy

Now this function also frees the perdomain mapping. It is safe to do so because destroy_perdomain_mapping is idempotent. Move free_perdomain_mappings after pv_domain_destroy. It is safe to do so because both destroy_perdomain_mapping and free_perdomain_mappings are idempotent. Signed-off-by: Wei

[Xen-devel] [PATCH for-next v3 00/12] x86: refactor x86/domain.c

Can be found at https://xenbits.xen.org/git-http/people/liuw/xen.git wip.x86-domain-v3 Cc: Jan Beulich Cc: Andrew Cooper Cc: Tim Deegan Cc: George Dunlap Wei Liu (12): x86/mm: make

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On Tue, Apr 25, 2017 at 03:52:06PM +0100, Andrew Cooper wrote: > > +if ( is_pv_32bit_domain(d) ) > > +{ > > +if ( (rc = setup_compat_arg_xlat(v)) ) > > +goto done; > > + > > +if ( (rc = setup_compat_l4(v)) ) > > +goto done; > > +} > > Now the

Re: [Xen-devel] superpages lost after migration of HVM domU

On Thu, Apr 20, Jan Beulich wrote: > >>> On 20.04.17 at 18:04, wrote: > > On Thu, Apr 20, Andrew Cooper wrote: > > > >> As it currently stands, the sending side iterates from 0 to p2m_size, > >> and sends every frame on the first pass. This means we get PAGE_DATA > >> records

Re: [Xen-devel] [PATCH 00/10] pl011 emulation support in Xen

Hi Julien, >> tools/console/client/main.c | 6 + >> tools/console/daemon/io.c| 532 >> +++ >> tools/libxc/include/xc_dom.h | 3 + >> tools/libxc/xc_dom_arm.c | 7 +- >> tools/libxc/xc_dom_boot.c| 3 + >>

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

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

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

>> This breaks on old compilers: >> >> FC-64 >> > ulator> >> gcc --version >> gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2) > I did try with 4.3.x, fwiw (but I'm afraid I've lost that machine just > now, and will hardly

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

At 08:07 -0600 on 26 Apr (1493194043), Jan Beulich wrote: > >>> On 25.04.17 at 12:59, wrote: > > Hi, > > > > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: > >> Jann's explanation of the problem: > >> > >> "start situation: > >> - domain A and domain B are PV domains >

Re: [Xen-devel] [PATCH for-4.9] seabios: run olddefconfig

>>> On 26.04.17 at 16:08, wrote: > Wei Liu writes ("[PATCH for-4.9] seabios: run olddefconfig"): >> We provided a base config file in 970f8de3e. To generate a full config >> file, running olddefconfig is required. >> >> Signed-off-by: Wei Liu >>

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

>>> On 26.04.17 at 16:01, wrote: > On 04/25/2017 05:04 AM, Jan Beulich wrote: >> Stub invocations need to have the space the stub occupies as an input, >> to prevent the compiler from re-ordering (or omitting) writes to it. >> >> Signed-off-by: Jan Beulich

[Xen-devel] [xen-unstable-smoke test] 107709: tolerable trouble: broken/pass - PUSHED

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

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

>>> On 26.04.17 at 15:32, wrote: > On Wed, Apr 26, 2017 at 07:26:29AM -0600, Jan Beulich wrote: >> >>> On 26.04.17 at 14:46, wrote: >> > On 26/04/17 13:39, Jan Beulich wrote: >> > On 25.04.17 at 16:52, wrote: >> >>>

Re: [Xen-devel] [PATCH for-4.9] seabios: run olddefconfig

Wei Liu writes ("[PATCH for-4.9] seabios: run olddefconfig"): > We provided a base config file in 970f8de3e. To generate a full config > file, running olddefconfig is required. > > Signed-off-by: Wei Liu > --- > Cc: Ian Jackson > Cc: Jan Beulich

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

>>> On 25.04.17 at 12:59, wrote: > Hi, > > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: >> Jann's explanation of the problem: >> >> "start situation: >> - domain A and domain B are PV domains >> - domain A and B both have currently scheduled vCPUs, and the vCPUs >>

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

flight 107713 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/107713/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 106986 build-amd64

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

On 04/25/2017 05:04 AM, Jan Beulich wrote: > Stub invocations need to have the space the stub occupies as an input, > to prevent the compiler from re-ordering (or omitting) writes to it. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++

Re: [Xen-devel] [PATCH] x86/xen: fix xsave capability setting

On 04/25/2017 02:47 AM, Juergen Gross wrote: > Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid > values for xsave") introduced a regression as it tried to make use of > the fixup feature before it being available. > > Fall back to the old variant testing via cpuid(). > >

[Xen-devel] [PATCH] xen/x86: Call xen_smp_intr_init_pv() on BSP

Recent code rework that split handling ov PV, HVM and PVH guests into separate files missed calling xen_smp_intr_init_pv() on CPU0. Add this call. Signed-off-by: Boris Ostrovsky Reported-by: Sander Eikelenboom --- arch/x86/xen/smp_pv.c | 2 +-

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

On Wed, Apr 26, 2017 at 07:29:34AM -0600, Jan Beulich wrote: > >>> On 26.04.17 at 14:56, wrote: > > On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote: > >> >>> On 25.04.17 at 15:52, wrote: > >> > --- a/xen/arch/x86/domain.c > >> > +++

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

On Wed, Apr 26, 2017 at 07:27:23AM -0600, Jan Beulich wrote: > >>> On 26.04.17 at 14:53, wrote: > > On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote: > >> > if ( is_hvm_domain(d) ) > >> > -{ > >> > rc = hvm_vcpu_initialise(v); > >> > -goto

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On Wed, Apr 26, 2017 at 07:26:29AM -0600, Jan Beulich wrote: > >>> On 26.04.17 at 14:46, wrote: > > On 26/04/17 13:39, Jan Beulich wrote: > > On 25.04.17 at 16:52, wrote: > >>> On 25/04/17 14:52, Wei Liu wrote: > - fail: > -

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

>>> On 26.04.17 at 14:56, wrote: > On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote: >> >>> On 25.04.17 at 15:52, wrote: >> > --- a/xen/arch/x86/domain.c >> > +++ b/xen/arch/x86/domain.c >> > @@ -536,6 +536,16 @@ static bool

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

>>> On 26.04.17 at 14:53, wrote: > On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote: >> > if ( is_hvm_domain(d) ) >> > -{ >> > rc = hvm_vcpu_initialise(v); >> > -goto done; >> > -} >> > - >> > - >> > -

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

>>> On 26.04.17 at 14:46, wrote: > On 26/04/17 13:39, Jan Beulich wrote: > On 25.04.17 at 16:52, wrote: >>> On 25/04/17 14:52, Wei Liu wrote: - fail: -pv_domain_destroy(d); - -return rc; -} -

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On Wed, Apr 26, 2017 at 01:46:53PM +0100, Andrew Cooper wrote: > On 26/04/17 13:39, Jan Beulich wrote: > On 25.04.17 at 16:52, wrote: > >> On 25/04/17 14:52, Wei Liu wrote: > >>> - fail: > >>> -pv_domain_destroy(d); > >>> - > >>> -return rc; > >>> -} > >>>

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

On Wed, Apr 26, 2017 at 06:32:46AM -0600, Jan Beulich wrote: > >>> On 25.04.17 at 15:52, wrote: > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d, > > uint32_t emflags) > >

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

On Wed, Apr 26, 2017 at 06:25:32AM -0600, Jan Beulich wrote: > > if ( is_hvm_domain(d) ) > > -{ > > rc = hvm_vcpu_initialise(v); > > -goto done; > > -} > > - > > - > > -spin_lock_init(>arch.pv_vcpu.shadow_ldt_lock); > > - > > -if ( !is_idle_domain(d) ) > > -

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On 26/04/17 13:39, Jan Beulich wrote: On 25.04.17 at 16:52, wrote: >> On 25/04/17 14:52, Wei Liu wrote: >>> - fail: >>> -pv_domain_destroy(d); >>> - >>> -return rc; >>> -} >>> - >>> +void paravirt_ctxt_switch_from(struct vcpu *v); >>> +void

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

>>> On 25.04.17 at 16:52, wrote: > On 25/04/17 14:52, Wei Liu wrote: >> - fail: >> -pv_domain_destroy(d); >> - >> -return rc; >> -} >> - >> +void paravirt_ctxt_switch_from(struct vcpu *v); >> +void paravirt_ctxt_switch_to(struct vcpu *v); >> int

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

On 26/04/17 07:04, Jan Beulich wrote: On 25.04.17 at 16:52, wrote: >> On 25/04/17 14:52, Wei Liu wrote: >>> + >>> +for_each_vcpu( d, v ) >>> +{ >>> +rc = setup_compat_arg_xlat(v); >>> +if ( !rc ) >>> +rc = setup_compat_l4(v); >>>

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

>>> On 25.04.17 at 15:52, wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d, > uint32_t emflags) > return true; > } > > +static void pv_domain_destroy(struct domain *d) > +{

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

>>> On 25.04.17 at 15:52, wrote: > +static int pv_vcpu_initialise(struct vcpu *v) > +{ > +struct domain *d = v->domain; > +int rc; > + > +ASSERT(!is_idle_domain(d)); > + > +spin_lock_init(>arch.pv_vcpu.shadow_ldt_lock); > + > +rc =

Re: [Xen-devel] [PATCH for-next v2 04/10] x86/domain: factor out pv_vcpu_destroy

>>> On 25.04.17 at 15:52, wrote: > The function is made idempotent on purpose. It may be worth mentioning that free_compat_arg_xlat() already is, as that's neither obvious nor the result of any earlier patch in this series. Jan

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Tue, Apr 25, 2017 at 10:22:00AM -0700, Stefano Stabellini wrote: > On Tue, 25 Apr 2017, Julien Grall wrote: > > On 24/04/17 20:16, Stefano Stabellini wrote: > > > Given the outstanding regression we need to fix as soon as possible, > > > I'll queue these patches on the xentip tree for 4.12. > >

[Xen-devel] [PATCH for-4.9] seabios: run olddefconfig

We provided a base config file in 970f8de3e. To generate a full config file, running olddefconfig is required. Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Jan Beulich Should fix

[Xen-devel] [ovmf baseline-only test] 71234: regressions - FAIL

This run is configured for baseline tests only. flight 71234 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71234/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

>>> On 26.04.17 at 05:30, wrote: > On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote: > On 26.04.17 at 02:52, wrote: >>> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline >>> pCPUs, which can theoretically decrease the maximum

Re: [Xen-devel] Is Xen supports banana PI?

Hello, On 26/04/2017 07:00, 유정우 wrote: Is Xen supports banana PI? Cause It’s A-20 but there’s no document for support banana-pi Xen should support most of processor with virtualization extension. The A20 SoC is also in use in the cubietruck that we already support. I would try to follow and

Re: [Xen-devel] [PULL 0/21] Please pull xen-20170421-v2-tag for 2.10

On 25 April 2017 at 19:34, Stefano Stabellini wrote: > Added a fix for the clang build, see > alpine.DEB.2.10.1704251014320.2875@sstabellini-ThinkPad-X260 > > > The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059: > > Update version for v2.9.0-rc1

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote: On 26.04.17 at 02:52, wrote: >> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline >> pCPUs, which can theoretically decrease the maximum of #entry >> in the list by N times. N is #pCPU. > >Why

Re: [Xen-devel] [PATCH v5] ns16550: Add support for UART parameters to be specifed with name-value pairs

>>> On 19.04.17 at 20:57, wrote: > Changed since v4: > * Changes from [PATCH v4] code review I'm sorry, but this is not enough. > @@ -77,6 +94,30 @@ static struct ns16550 { > #endif > } ns16550_com[2] = { { 0 } }; > > +struct serial_param_var { > +const char

Re: [Xen-devel] [seabios bisection] complete build-amd64-xsm

Jan Beulich writes ("Re: [Xen-devel] [seabios bisection] complete build-amd64-xsm"): > On 26.04.17 at 04:27, wrote: > > Bug is in tree: xen git://xenbits.xen.org/xen.git > > Bug introduced: 99704f26360ee8d4f85081c6c50ce64f47961f6d > > Bug not present:

Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface

On Fri, Apr 14, 2017 at 1:12 PM, Oleksandr Grytsov wrote: > On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson > wrote: >> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV >> display device driver interface"): >>> After internal

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

Oleksandr Tyshchenko writes ("Re: [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl"): > On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu wrote: > > Let me explain where I'm coming from: > > > > 1. if not populating the iommu page table causes Xen to malfunction > >

Re: [Xen-devel] [PATCH] dom_ids array implementation.

>>> On 20.04.17 at 07:38, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -125,6 +125,8 @@ struct feat_node { > uint32_t cos_reg_val[MAX_COS_REG_CNT]; > }; > > +#define PSR_DOM_IDS_NUM ((DOMID_IDLE + 1) / sizeof(uint32_t)) Instead of this,

  1   2   >