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

flight 102318 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102318/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 102286

[Xen-devel] [ovmf test] 102330: regressions - FAIL

flight 102330 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102330/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Thursday, November 17, 2016 1:45 AM > > On 11/16/2016 12:34 PM, Andrew Cooper wrote: > > On 16/11/16 17:34, Boris Ostrovsky wrote: > >> On 11/16/2016 12:10 PM, Andrew Cooper wrote: > >>> On 16/11/16 16:40, Boris Ostrovsky wrote:

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 16, 2016 8:32 PM > > core2_no_vpmu_ops exists solely to work around the default-leaking of > CPUID/MSR > values in Xen. > > With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last >

Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, November 16, 2016 9:34 PM > > >>> On 16.11.16 at 14:01, wrote: > > On 16/11/16 12:53, Jan Beulich wrote: > > On 16.11.16 at 13:31, wrote: > >>> This reduces the net

Re: [Xen-devel] [PATCH v7 06/11] x86, paravirt: Add interface to support kvm/xen vcpu preempted check

在 2016/11/16 18:23, Peter Zijlstra 写道: On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote: Hi, Peter. I think we can avoid a function call in a simpler way. How about below static inline bool vcpu_is_preempted(int cpu) { /* only set in pv case*/ if

Re: [Xen-devel] [PATCH V5] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT

> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: Wednesday, November 16, 2016 3:49 PM > > On 11/16/2016 09:22 AM, Tian, Kevin wrote: > > Looks not working with APICv virtual interrupt delivery... > > It's only meant to work with "regular" injections (we'd like to be able > to

Re: [Xen-devel] [PATCH for-4.9] x86/vmx: Shorten vmx_{get, set}_segment_register() for user segments

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, November 16, 2016 9:42 PM > > On 26/10/16 14:15, Andrew Cooper wrote: > > The x86_segment enumeration matches hardware SReg encoding, which can be > > used > > to calculate the appropriate VMCS fields, rather than open

[Xen-devel] [ovmf test] 102322: regressions - FAIL

flight 102322 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102322/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

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

flight 102310 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102310/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909

Re: [Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

On 17/11/2016 00:00, Boris Ostrovsky wrote: >> When we want to enable ACPI vcpu hotplug for HVM guests, What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests, aren't we? >>> Are we? If so, how? >>> >>> I don't see any toolstack or qemu code able to cope with APCI CPU

Re: [Xen-devel] [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests

> > When we want to enable ACPI vcpu hotplug for HVM guests, >>> What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests, >>> aren't we? >> Are we? If so, how? >> >> I don't see any toolstack or qemu code able to cope with APCI CPU >> hotplug. I can definitely see ACPI PCI

[Xen-devel] [xen-unstable baseline-only test] 68050: regressions - FAIL

This run is configured for baseline tests only. flight 68050 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68050/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub 10 guest-start

[Xen-devel] [ovmf test] 102314: regressions - FAIL

flight 102314 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102314/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

[Xen-devel] [PATCH v1 4/7] OssTest: Add target_cmd_root_rc which returns return code.

All the different target_cmd_* end up calling tcmdex which has the unfortunate side-effect of calling 'die' if the SSH sessions results in any return code not zero. That is fine, except for tests where we want to get a non-zero return value. This patch moves the: die "status $r" from tcmdex to

[Xen-devel] [PATCH v1 7/7] make-flight/mfi-common: Add them in the matrix.

Signed-off-by: Konrad Rzeszutek Wilk --- make-flight | 12 mfi-common | 9 + 2 files changed, 21 insertions(+) diff --git a/make-flight b/make-flight index d45a0e3..c2add66 100755 --- a/make-flight +++ b/make-flight @@ -485,6 +485,17 @@

[Xen-devel] [PATCH v1 6/7] sg-run-job: Add the test-livepatch.

Signed-off-by: Konrad Rzeszutek Wilk --- sg-run-job | 5 + 1 file changed, 5 insertions(+) diff --git a/sg-run-job b/sg-run-job index c5cc3c6..7e326b9 100755 --- a/sg-run-job +++ b/sg-run-job @@ -421,6 +421,11 @@ proc run-job/test-xtf {} { run-ts . = ts-xtf-run

[Xen-devel] [PATCH v1 5/7] ts-livepatch: Initial test-cases.

There are 32 test-cases in there. Before we run any of them we verify that the payload files are present in /usr/lib/debug. If so we go through all of the test-cases. Signed-off-by: Konrad Rzeszutek Wilk --- ts-livepatch | 102

[Xen-devel] [PATCH v1 1/7] ts-xen-build: Enable livepatch.

Livepatch compiles and works on x86/ARM{32|64} so we can unconditionaly enable it. Signed-off-by: Konrad Rzeszutek Wilk --- ts-xen-build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ts-xen-build b/ts-xen-build index 4f1f71a..c567054 100755 --- a/ts-xen-build +++

[Xen-devel] [PATCH v1 3/7] ts-xen-build: Install livepatch regressions tests.

That come with the Xen git tree (see xen/test/). Signed-off-by: Konrad Rzeszutek Wilk --- ts-xen-build | 7 +++ 1 file changed, 7 insertions(+) diff --git a/ts-xen-build b/ts-xen-build index 9843c2e..1b36b9c 100755 --- a/ts-xen-build +++ b/ts-xen-build @@ -170,6

[Xen-devel] [PATCH v1 2/7] ts-xen-build: Build the livepatch test-cases

Signed-off-by: Konrad Rzeszutek Wilk --- ts-xen-build | 5 + 1 file changed, 5 insertions(+) diff --git a/ts-xen-build b/ts-xen-build index c567054..9843c2e 100755 --- a/ts-xen-build +++ b/ts-xen-build @@ -165,6 +165,11 @@ END END store_runvar("flaskpolicy",

[Xen-devel] [PATCH v1] OSSTest test-harness for livepatches.

Heya! With this test-harness I am able to run the regressions tests on livepatches on Xen 4.8. I only used the standalone tests. The incantations was: To prep: ./sg-run-job build-amd64 ./sg-run-job build-amd64-pvops And then to run: ./sg-run-job test-amd64-amd64-livepatch There are still some

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

flight 102302 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102302/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 14 guest-stop fail REGR. vs. 102286

Re: [Xen-devel] Xen ARM community call

I will like to attend GMT -6. Thanks, Sameer On 11/8/2016 5:19 AM, Julien Grall wrote: Hi all, I would like to start organizing a recurring community call to discuss and sync-up on upcoming features for Xen ARM. Example of features that could be discussed: - Sharing co-processor between

[Xen-devel] [ovmf test] 102305: regressions - FAIL

flight 102305 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102305/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

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

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

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

flight 102308 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102308/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] Error regarding filesystem in Dom0 in lager board

Hi, Try to use attached files as DTS. I didn't tested, but looks like there are few missed nodes: - hypervisor - psci I'm not sure, that Linux & Xen will correctly inter-works without them. With the best regards, Iurii Mykhalskyi On Wed, Nov 16, 2016 at 7:23 PM, George John

Re: [Xen-devel] [PATCH v3.1 10/15] xen/x86: split Dom0 build into PV and PVHv2

On Fri, Nov 11, 2016 at 09:53:49AM -0700, Jan Beulich wrote: > >>> On 29.10.16 at 10:59, wrote: > > --- a/xen/arch/x86/domain_build.c > > +++ b/xen/arch/x86/domain_build.c > > @@ -191,10 +191,8 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain > > *dom0) > > } > > >

[Xen-devel] [PATCH v2] x86/svm: Improve segment register printing in svm_vmcb_dump()

v2 patch FYI. I have queued this in my for-4.9 branch, for merging when we branch. ~Andrew ---%<--- This makes it more succinct and easier to read. Before: (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0 (XEN) CS: sel=0x0008, attr=0x029b, limit=0x, base=0x (XEN)

[Xen-devel] [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently that this flag causes get_user_pages() to always fail with -EFAULT. check_vma_flags __get_user_pages

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 11/16/2016 12:34 PM, Andrew Cooper wrote: > On 16/11/16 17:34, Boris Ostrovsky wrote: >> On 11/16/2016 12:10 PM, Andrew Cooper wrote: >>> On 16/11/16 16:40, Boris Ostrovsky wrote: On 11/16/2016 07:31 AM, Andrew Cooper wrote: > @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input,

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 16/11/16 17:34, Boris Ostrovsky wrote: > On 11/16/2016 12:10 PM, Andrew Cooper wrote: >> On 16/11/16 16:40, Boris Ostrovsky wrote: >>> On 11/16/2016 07:31 AM, Andrew Cooper wrote: @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 11/16/2016 12:10 PM, Andrew Cooper wrote: > On 16/11/16 16:40, Boris Ostrovsky wrote: >> On 11/16/2016 07:31 AM, Andrew Cooper wrote: >>> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int >>> *eax, unsigned int *ebx, >>> >>> *ebx &=

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

flight 102290 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/102290/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909

[Xen-devel] Error regarding filesystem in Dom0 in lager board

Hi, I just bumped in to some errors related to filesystem . The following is the log. I am using xen 4.7.1 along with linux kernel 3.19.8 as Dom0 Starting kernel ... - UART enabled - - CPU booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

On 11/16/2016 10:48 AM, Boris Ostrovsky wrote: On 11/16/2016 08:43 AM, Andrew Cooper wrote: On 31/10/16 13:48, Andrew Cooper wrote: This makes it more succinct and easier to read. Before: (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0 (XEN) CS: sel=0x0008, attr=0x029b, limit=0x,

Re: [Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On 16/11/16 17:02, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. > > It was discovered recently this this flag may cause page allocation > failures

Re: [Xen-devel] [PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On Wed, Nov 16, 2016 at 07:09:01AM +0100, Juergen Gross wrote: > On 15/11/16 01:11, Alex Thorlton wrote: > > On systems with sufficiently large e820 tables, and several IOAPICs, it > > is possible for the XENMEM_machine_memory_map callback (and its > > counterpart, XENMEM_memory_map) to attempt to

Re: [Xen-devel] [PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On Tue, Nov 15, 2016 at 07:30:35AM +0100, Ingo Molnar wrote: > > * Alex Thorlton wrote: > > > On systems with sufficiently large e820 tables, and several IOAPICs, it > > is possible for the XENMEM_machine_memory_map callback (and its > > counterpart, XENMEM_memory_map) to

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 16/11/16 16:40, Boris Ostrovsky wrote: > On 11/16/2016 07:31 AM, Andrew Cooper wrote: >> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, >> unsigned int *ebx, >> >> *ebx &= hvm_featureset[FEATURESET_e8b]; >> break; >> + >> +case 0x801c:

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

On 16/11/16 17:09, Boris Ostrovsky wrote: > On 11/16/2016 12:04 PM, Andrew Cooper wrote: >> On 16/11/16 16:27, Boris Ostrovsky wrote: >>> On 11/16/2016 07:31 AM, Andrew Cooper wrote: diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c index a542f4d..1f822ca 100644 ---

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

On 16/11/16 15:53, Jan Beulich wrote: On 16.11.16 at 13:31, wrote: >> @@ -961,13 +962,38 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t >> sub_idx, >> } >> break; >> >> -case 4: >> -if ( !has_hvm_container_domain(currd) ) >>

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 16/11/16 15:20, Jan Beulich wrote: On 16.11.16 at 13:31, wrote: >> @@ -3676,6 +3671,12 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, >> unsigned int *ebx, >> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) ) >>

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

On 11/16/2016 12:04 PM, Andrew Cooper wrote: > On 16/11/16 16:27, Boris Ostrovsky wrote: >> On 11/16/2016 07:31 AM, Andrew Cooper wrote: >>> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c >>> index a542f4d..1f822ca 100644 >>> --- a/xen/arch/x86/cpu/vpmu.c >>> +++

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

On 16/11/16 16:27, Boris Ostrovsky wrote: > On 11/16/2016 07:31 AM, Andrew Cooper wrote: >> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c >> index a542f4d..1f822ca 100644 >> --- a/xen/arch/x86/cpu/vpmu.c >> +++ b/xen/arch/x86/cpu/vpmu.c >> @@ -136,9 +136,10 @@ int

[Xen-devel] [PATCH] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently this this flag may cause page allocation failures with the following stack: check_vma_flags

Re: [Xen-devel] [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On Wed, Nov 16, 2016 at 05:42:11PM +0100, Juergen Gross wrote: > On 15/11/16 08:15, Jan Beulich wrote: > On 15.11.16 at 07:33, wrote: > >> On 15/11/16 01:11, Alex Thorlton wrote: > >>> Hey everyone, > >>> > >>> We're having problems with large systems hitting a BUG in > >>>

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

On Fri, Nov 11, 2016 at 03:04:49AM -0700, Jan Beulich wrote: > >>> On 10.11.16 at 18:21, wrote: > > On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote: > >> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function > >> > (rev 01) > >> >

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

On 11/16/2016 08:43 AM, Andrew Cooper wrote: > On 31/10/16 13:48, Andrew Cooper wrote: >> This makes it more succinct and easier to read. >> >> Before: >> (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0 >> (XEN) CS: sel=0x0008, attr=0x029b, limit=0x, >> base=0x >>

Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices

On Thu, Nov 10, 2016 at 09:37:19AM -0700, Jan Beulich wrote: > >>> On 10.11.16 at 11:39, wrote: > > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote: > >> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote: > >> > PCI memory BARs > >> >

Re: [Xen-devel] [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On 15/11/16 08:15, Jan Beulich wrote: On 15.11.16 at 07:33, wrote: >> On 15/11/16 01:11, Alex Thorlton wrote: >>> Hey everyone, >>> >>> We're having problems with large systems hitting a BUG in >>> xen_memory_setup, due to extra e820 entries created in the >>>

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 11/16/2016 07:31 AM, Andrew Cooper wrote: > @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, > unsigned int *ebx, > > *ebx &= hvm_featureset[FEATURESET_e8b]; > break; > + > +case 0x801c: > +if ( !(v->arch.xcr0 & XSTATE_LWP) ) > +

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

On 11/16/2016 07:31 AM, Andrew Cooper wrote: > diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c > index a542f4d..1f822ca 100644 > --- a/xen/arch/x86/cpu/vpmu.c > +++ b/xen/arch/x86/cpu/vpmu.c > @@ -136,9 +136,10 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content, > const

Re: [Xen-devel] [PATCH 6/6] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

>>> On 16.11.16 at 13:31, wrote: > @@ -961,13 +962,38 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t > sub_idx, > } > break; > > -case 4: > -if ( !has_hvm_container_domain(currd) ) > +case 4: /* HVM hypervisor leaf. */ > +

Re: [Xen-devel] [PATCH 5/6] x86/time: Move cpuid_time_leaf() handling into cpuid_hypervisor_leaves()

>>> On 16.11.16 at 13:31, wrote: > This reduces the net complexity of CPUID handling by having all adjustments in > at the same place. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

Re: [Xen-devel] [PATCH v2] tools/libacpi: Be specific about which DSDT files to build

On Tue, Nov 15, 2016 at 09:09:18AM -0700, Jan Beulich wrote: > >>> On 15.11.16 at 17:04, wrote: > > There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We > > pass which DSDTs to build via DSDT_FILES parameter. > > > > If DSDT_FILES is empty all

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

> For example, take a look at PVCalls which is entirely based on data > copies: > > http://marc.info/?l=xen-devel=147639616310487 > > > I have already shown that it performs better than netfront/netback on > x86 in this blog post: > >

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

>>> On 16.11.16 at 13:31, wrote: > @@ -3676,6 +3671,12 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, > unsigned int *ebx, > if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) ) > *edx &= ~cpufeat_mask(X86_FEATURE_PSE36); >

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

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

Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

Julien, >> What we estimate now is a thin Dom0 without any drivers running with >> ramdisk. All drivers would be moved to a special guest domain. > > You may want to give a look what has been done on x86 with the "Dedicated > hardware domain". I have to look at the stuff. > Another solution, is

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

On Wed, Nov 16, 2016 at 03:56:04AM -0700, Jan Beulich wrote: > >>> On 16.11.16 at 11:51, wrote: > > vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps > > back around to 0. Instead, complain if the reported length is greater than > > 15 > > and

[Xen-devel] [ovmf test] 102298: regressions - FAIL

flight 102298 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102298/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

On 16 November 2016 at 15:31, David Vrabel wrote: > On 16/11/16 13:12, Volodymyr Babchuk wrote: >> Hello David, >> >> I helped Oleksandr with parts of this protocol, so I want to address >> some questions you asked. >> >> On 16 November 2016 at 12:38, David Vrabel

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

Hello David, I helped Oleksandr with parts of this protocol, so I want to address some questions you asked. On 16 November 2016 at 12:38, David Vrabel wrote: > > Sound is not my area of expertise but I have a few points that you may > like to consider. > > 1. You can

Re: [Xen-devel] [PATCH 1/1] sched: provide common cpu_relax_yield definition

Am 16.11.2016 um 13:23 schrieb Christian Borntraeger: No need to duplicate the same define everywhere. Since the only user is stop-machine and the only provider is s390, we can use a default implementation of cpu_relax_yield in sched.h. Suggested-by: Russell King

Re: [Xen-devel] [PATCH] x86/svm: Improve segment register printing in svm_vmcb_dump()

On 31/10/16 13:48, Andrew Cooper wrote: > This makes it more succinct and easier to read. > > Before: > (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0 > (XEN) CS: sel=0x0008, attr=0x029b, limit=0x, base=0x > (XEN) DS: sel=0x0033, attr=0x0cf3, limit=0x,

Re: [Xen-devel] [RFC] Shared coprocessor framework

> So it looks like there could be an generic API to deal with > these various operations. Currently it is designed to be a generic API with platform (coprocessor) specific hooks. > And I think you are thinking to hook it up to the scheduler so that when a > guest > switches you can follow with

Re: [Xen-devel] [PATCH for-4.9] x86/vmx: Shorten vmx_{get, set}_segment_register() for user segments

On 26/10/16 14:15, Andrew Cooper wrote: > The x86_segment enumeration matches hardware SReg encoding, which can be used > to calculate the appropriate VMCS fields, rather than open coding every > instance. > > This reduces the size of the switch statement, and the number of embedded BUG > frames

Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

>>> On 16.11.16 at 14:01, wrote: > On 16/11/16 12:53, Jan Beulich wrote: > On 16.11.16 at 13:31, wrote: >>> This reduces the net complexity of CPUID handling by having all adjustments >>> in >>> at the same place. Remove the now-unused

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

On 16/11/16 13:12, Volodymyr Babchuk wrote: > Hello David, > > I helped Oleksandr with parts of this protocol, so I want to address > some questions you asked. > > On 16 November 2016 at 12:38, David Vrabel wrote: >> >> Sound is not my area of expertise but I have a few

Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

On 16/11/16 12:53, Jan Beulich wrote: On 16.11.16 at 13:31, wrote: >> This reduces the net complexity of CPUID handling by having all adjustments >> in >> at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure. > I have to admit that I'm not

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

flight 102296 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/102296/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] OSSTest, standalone, weird end of invocation.

Konrad Rzeszutek Wilk writes ("OSSTest, standalone, weird end of invocation."): > I've my test machine, and I can run some of the standalone > tests. But everytime I run any of the jobs I get: Erk. Try this. Ian. diff --git a/tcl/JobDB-Standalone.tcl b/tcl/JobDB-Standalone.tcl index

Re: [Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

>>> On 16.11.16 at 13:31, wrote: > core2_no_vpmu_ops exists solely to work around the default-leaking of > CPUID/MSR > values in Xen. > > With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last > remaining hook. Since core2_no_vpmu_ops's

Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

>>> On 16.11.16 at 13:31, wrote: > This reduces the net complexity of CPUID handling by having all adjustments in > at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure. I have to admit that I'm not convinced this is a good idea at this point, due

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

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

[Xen-devel] [distros-debian-squeeze test] 68048: tolerable FAIL

flight 68048 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68048/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 68018

Re: [Xen-devel] [PATCH 1/6] xen/x86: Add a helper to calculate family/model/stepping information

On 16/11/16 12:49, Jan Beulich wrote: On 16.11.16 at 13:31, wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -183,6 +183,25 @@ int get_cpu_vendor(const char v[], enum get_cpu_vendor >> mode) >> return X86_VENDOR_UNKNOWN; >>

Re: [Xen-devel] [PATCH v1 2/2] kexec: Support -S paramter to return whether the kexec payload is loaded.

On Mon, Nov 14, 2016 at 05:12:53PM -0500, Konrad Rzeszutek Wilk wrote: > Instead of the scripts having to poke at various fields we can > provide that functionality via the -S parameter. > > Returns 0 if the payload is loaded. Can be used in combination > with -l or -p to get the state of the

Re: [Xen-devel] [PATCH 1/6] xen/x86: Add a helper to calculate family/model/stepping information

>>> On 16.11.16 at 13:31, wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -183,6 +183,25 @@ int get_cpu_vendor(const char v[], enum get_cpu_vendor > mode) > return X86_VENDOR_UNKNOWN; > } > > +u8 get_cpu_family(uint32_t raw, u8

Re: [Xen-devel] [PATCH 1/1] sched: provide common cpu_relax_yield definition

On Wed, Nov 16, 2016 at 01:23:05PM +0100, Christian Borntraeger wrote: > No need to duplicate the same define everywhere. Since > the only user is stop-machine and the only provider is > s390, we can use a default implementation of cpu_relax_yield > in sched.h. > > Suggested-by: Russell King

Re: [Xen-devel] [RFC] Shared coprocessor framework

AM> The situation is not as bad as having full-scope driver (which is AM> implemented in some proprietary hypervisors), we only need to: AM> 1. stop AM> 2. flush registers AM> 3. switch memory context <--- implemented by SMMU in ARM AM> 4. restore registers AM> 5. start Well, we also need to take

[Xen-devel] [PATCH for-4.9 0/6] Introductory cleanup for CPUID phase 2 work

This is some cleanup intended to ease the development of further development work. There is no practical change from a guests point of view. Andrew Cooper (6): xen/x86: Add a helper to calculate family/model/stepping information x86/vpmu: Move vpmu_do_cpuid() handling into {pv,hvm}_cpuid()

[Xen-devel] [PATCH 6/6] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf() infrastructure. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

[Xen-devel] [PATCH 5/6] x86/time: Move cpuid_time_leaf() handling into cpuid_hypervisor_leaves()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/time.c| 36 xen/arch/x86/traps.c

[Xen-devel] [PATCH 1/6] xen/x86: Add a helper to calculate family/model/stepping information

And replace the existing opencoded calculations. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpu/common.c | 36 ++-- xen/arch/x86/domctl.c | 7 +--

[Xen-devel] [PATCH 3/6] x86/vpmu: Remove core2_no_vpmu_ops

core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR values in Xen. With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu intel: Add cpuid handling when vpmu

[Xen-devel] [PATCH 2/6] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure. This involves introducing a vpmu_enabled() predicate, and making the Intel specific VPMU_CPU_HAS_* constants public. Signed-off-by: Andrew

[Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused hvm_funcs.cpuid_intercept infrastructure. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

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

flight 102286 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/102286/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102258

Re: [Xen-devel] OSSTest, standalone, weird end of invocation.

On Tue, Nov 15, 2016 at 04:07:03PM -0500, Konrad Rzeszutek Wilk wrote: > Hey Ian, > > I've my test machine, and I can run some of the standalone > tests. But everytime I run any of the jobs I get: > > .. snip.. > 2016-11-16 00:07:55 Z setting xtfbuildjob=build-amd64-xtf > 2016-11-16 00:07:55 Z

[Xen-devel] [PATCH 1/1] sched: provide common cpu_relax_yield definition

No need to duplicate the same define everywhere. Since the only user is stop-machine and the only provider is s390, we can use a default implementation of cpu_relax_yield in sched.h. Suggested-by: Russell King Signed-off-by: Christian Borntraeger

Re: [Xen-devel] [PATCH v7 06/11] x86, paravirt: Add interface to support kvm/xen vcpu preempted check

On Wed, Nov 16, 2016 at 12:29:44PM +0100, Christian Borntraeger wrote: > On 11/16/2016 11:23 AM, Peter Zijlstra wrote: > > On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote: > >> Hi, Peter. > >>I think we can avoid a function call in a simpler way. How about below > >> > >> static

Re: [Xen-devel] [PATCH v7 06/11] x86, paravirt: Add interface to support kvm/xen vcpu preempted check

On 11/16/2016 11:23 AM, Peter Zijlstra wrote: > On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote: >> Hi, Peter. >> I think we can avoid a function call in a simpler way. How about below >> >> static inline bool vcpu_is_preempted(int cpu) >> { >> /* only set in pv case*/ >>

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

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-qcow2

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qcow2 testid debian-di-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu

Re: [Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

>>> On 16.11.16 at 11:51, wrote: > vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps > back around to 0. Instead, complain if the reported length is greater than 15 > and use x86_decode_insn() as a fallback. > > While making changes here, fix

[Xen-devel] [PATCH for-4.8] x86/svm: Fix svm_nextrip_insn_length() when crossing the virtual boundary to 0

vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps back around to 0. Instead, complain if the reported length is greater than 15 and use x86_decode_insn() as a fallback. While making changes here, fix two whitespace issues with the case labels. Signed-off-by: Andrew

Re: [Xen-devel] [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.

Sound is not my area of expertise but I have a few points that you may like to consider. 1. You can only say how many channels a stream has, not what the channels correspond to (e.g., "left", "right" for a 2 channel stereo stream; or "left-front", "rear-right", etc. for a 6 channel 5.1 surround

  1   2   >