[Xen-devel] [xen-4.8-testing baseline-only test] 72462: regressions - FAIL

This run is configured for baseline tests only. flight 72462 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72462/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 16

[Xen-devel] [xen-4.6-testing test] 116250: regressions - FAIL

flight 116250 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116250/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 115190 Tests which

[Xen-devel] [xen-4.5-testing test] 116245: regressions - FAIL

flight 116245 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116245/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115226

[Xen-devel] [xen-4.7-testing test] 116240: regressions - FAIL

flight 116240 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116240/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 6 xen-build fail in 116219 REGR. vs. 115210 Tests which

[Xen-devel] [xen-4.8-testing test] 116237: regressions - FAIL

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

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

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-amd64 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

Re: [Xen-devel] [PATCH 10/13] x86/alternative: Support indirect call replacement

On 10/04/17 08:58, Josh Poimboeuf wrote: > Add alternative patching support for replacing an instruction with an > indirect call. This will be needed for the paravirt alternatives. I have a patchset that generalizes the alternatives in what I think is a more robust way. I really, really want to

Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote: > On 17/11/17 19:07, Borislav Petkov wrote: > > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > >> Convert the hard-coded native patch assembly code strings to macros to > >> facilitate sharing common code between

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

Hello, On 15 November 2017 at 11:34, Jayadev Kumaran wrote: >>> What defconfig are you based on? Do you have a device-tree support >>> enabled? > I use omap2plus_defconfig . Yes , device tree support is there and the dts > file used is omap5-uevm.dts Some options in

Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On 17/11/17 19:07, Borislav Petkov wrote: > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: >> Convert the hard-coded native patch assembly code strings to macros to >> facilitate sharing common code between 32-bit and 64-bit. >> >> These macros will also be used by a future patch

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

On 17 November 2017 at 12:15, Volodymyr Babchuk wrote: > Hi Jayadev, > > On 17 November 2017 at 13:53, Andrii Anisov wrote: >>> >>> Is there a way to debug which one of the above two possibilities has lead >>> to the issue ? >> >> Four years ago I

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

On 8 November 2017 at 14:52, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 08, 2017 at 10:47:20AM +0530, Jayadev Kumaran wrote: >> Hello all, >> >> I'm trying to implement Xen hypervisor support on OMAP5432.I have followed >> the steps as in >>

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On Fri, Nov 17, 2017 at 4:01 PM, Julien Grall wrote: > Hi, Hi, Julien. > > First of all, thank you Oleksandr for starting a thread around CPUFreq > support. Thank you for the valued comments. > > On 11/16/2017 05:04 PM, Andre Przywara wrote: >> >> On 16/11/17 14:57,

Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of

Re: [Xen-devel] [libvirt test] 116216: regressions - FAIL

On 11/16/2017 11:51 AM, Julien Grall wrote: Hi all, On 16 November 2017 at 09:40, osstest service owner wrote: flight 116216 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/116216/ Regressions :-( Tests which did not succeed and are

[Xen-devel] [xen-4.9-testing test] 116234: tolerable FAIL - PUSHED

flight 116234 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/116234/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 116220 pass in 116234

Re: [Xen-devel] [xen-4.6-testing test] 116222: regressions - FAIL

On 17/11/17 17:21, Ian Jackson wrote: > osstest service owner writes ("[xen-4.6-testing test] 116222: regressions - > FAIL"): >> flight 116222 xen-4.6-testing real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/116222/ >> >> Regressions :-( >> >> Tests which did not succeed and are

Re: [Xen-devel] [xen-4.6-testing test] 116222: regressions - FAIL

osstest service owner writes ("[xen-4.6-testing test] 116222: regressions - FAIL"): > flight 116222 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/116222/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On Fri, Nov 17, 2017 at 6:41 PM, Andre Przywara wrote: > Hi, Hi Andre > > > >>> So Xen does not need to throw in its own ideas here. Which would avoid >>> some of the hard problems we encountered. >> I got all your point. >> Just question. Why does existing

Re: [Xen-devel] [xen-4.8-testing test] 116221: regressions - FAIL

osstest service owner writes ("[xen-4.8-testing test] 116221: regressions - FAIL"): > flight 116221 xen-4.8-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/116221/ > > Regressions :-( ... > version targeted for testing: > xen

Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map

On 17/11/17 12:47, Juergen Gross wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. > > Signed-off-by: Juergen Gross

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, >> So Xen does not need to throw in its own ideas here. Which would avoid >> some of the hard problems we encountered. > I got all your point. > Just question. Why does existing CPUFreq on x86 have own logic? Do we have > something yet another on ARM that having own logic in Xen doesn't

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

flight 116229 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/116229/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 116217 REGR. vs. 115539 Tests which are

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

flight 116227 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/116227/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-install fail REGR. vs. 116190 Tests which did

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

On Thu, Nov 16, 2017 at 7:04 PM, Andre Przywara wrote: > Hi, Hi Andre Thank you for your comments! > > On 16/11/17 14:57, Oleksandr Tyshchenko wrote: >> On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara >> wrote: >>> Hi, >> Hi Andre, Jassi >>

Re: [Xen-devel] [PATCH 01/13] x86/paravirt: remove wbinvd() paravirt interface

On Wed, Oct 04, 2017 at 10:58:22AM -0500, Josh Poimboeuf wrote: > Since lguest was removed, only the native version of wbinvd() is used. > The paravirt interface is no longer needed. > > Signed-off-by: Josh Poimboeuf > --- > arch/x86/include/asm/paravirt.h | 5 - >

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

flight 116226 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/116226/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 115643

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, First of all, thank you Oleksandr for starting a thread around CPUFreq support. On 11/16/2017 05:04 PM, Andre Przywara wrote: On 16/11/17 14:57, Oleksandr Tyshchenko wrote: On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara wrote: Anyway, I think we should go

Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map

On 17/11/17 13:26, Jan Beulich wrote: On 17.11.17 at 12:47, wrote: >> Make sure the HVM mmio area (especially console and Xenstore pages) is >> marked as "reserved" in the guest's E820 map, as otherwise conflicts >> might arise later, e.g. when hotplugging memory into the

Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map

>>> On 17.11.17 at 12:47, wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. This is very certainly wrong. Have

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On 2017-11-17 19:36, Thomas Gleixner wrote: On Fri, 17 Nov 2017, Quan Xu wrote: On 2017-11-16 17:53, Thomas Gleixner wrote: That's just plain wrong. We don't want to see any of this PARAVIRT crap in anything outside the architecture/hypervisor interfacing code which really needs it. The

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

Hi Jayadev, On 17 November 2017 at 13:53, Andrii Anisov wrote: >> >> Is there a way to debug which one of the above two possibilities has lead >> to the issue ? > > Four years ago I did it in a following way: > - wire up to UART2 pins on an expansion connector (this

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record

>>> On 16.11.17 at 23:45, wrote: > Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a > bug whereby it corrupts the HVM context stream if some, but fewer than the > maximum number of MSRs are written. > > _hvm_init_entry() creates an

Re: [Xen-devel] [PATCH for-4.10] tools/libxc: Fix restoration of PV MSRs after migrate

>>> On 16.11.17 at 22:13, wrote: > There are two bugs in process_vcpu_msrs() which clearly demonstrate that I > didn't test this bit of Migration v2 very well when writing it... > > vcpu->msrsz is always expected to be a multiple of xen_domctl_vcpu_msr_t > records in a

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream

>>> On 16.11.17 at 20:15, wrote: > Doing so amounts to silent state corruption, and must be avoided. I think a little more explanation is needed on why the current code is insufficient. Note specifically this for ( i = 0; !err && i < ctxt->count; ++i ) {

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

Hello Jayadev, On 15.11.17 13:34, Jayadev Kumaran wrote: Hello Andrii, >> What defconfig are you based on? Do you have a device-tree support enabled? I use /omap2plus_defconfig/ . Yes , device tree support is there and the dts file used is /omap5-uevm.dts >> /But it did not get a command

Re: [Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map

On Fri, Nov 17, 2017 at 12:47:33PM +0100, Juergen Gross wrote: > Make sure the HVM mmio area (especially console and Xenstore pages) is > marked as "reserved" in the guest's E820 map, as otherwise conflicts > might arise later, e.g. when hotplugging memory into the guest. > > Signed-off-by:

[Xen-devel] [PATCH for-4.10] tools/libxl: mark hvm mmio area as reserved in e820 map

Make sure the HVM mmio area (especially console and Xenstore pages) is marked as "reserved" in the guest's E820 map, as otherwise conflicts might arise later, e.g. when hotplugging memory into the guest. Signed-off-by: Juergen Gross --- This is a bugfix for PVH and HVM guests.

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Fri, 17 Nov 2017, Quan Xu wrote: > On 2017-11-16 17:53, Thomas Gleixner wrote: > > That's just plain wrong. We don't want to see any of this PARAVIRT crap in > > anything outside the architecture/hypervisor interfacing code which really > > needs it. > > > > The problem can and must be solved

Re: [Xen-devel] [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On 2017-11-16 17:53, Thomas Gleixner wrote: On Thu, 16 Nov 2017, Quan Xu wrote: On 2017-11-16 06:03, Thomas Gleixner wrote: --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record

On Thu, Nov 16, 2017 at 10:45:16PM +, Andrew Cooper wrote: > Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a > bug whereby it corrupts the HVM context stream if some, but fewer than the > maximum number of MSRs are written. > > _hvm_init_entry() creates an

Re: [Xen-devel] [PATCH for-4.10] tools/libxc: Fix restoration of PV MSRs after migrate

On Thu, Nov 16, 2017 at 09:13:22PM +, Andrew Cooper wrote: > There are two bugs in process_vcpu_msrs() which clearly demonstrate that I > didn't test this bit of Migration v2 very well when writing it... > > vcpu->msrsz is always expected to be a multiple of xen_domctl_vcpu_msr_t > records in

Re: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't ignore unknown MSRs in the migration stream

On Thu, Nov 16, 2017 at 07:15:32PM +, Andrew Cooper wrote: > Doing so amounts to silent state corruption, and must be avoided. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel

Re: [Xen-devel] XSA 243 v5 is missing the second patch for xen 4.8

>>> On 16.11.17 at 21:01, wrote: > Hello, > Looking at > https://xenbits.xen.org/xsa/advisory-243.html, > I cannot find the second patch for xen 4.8, xsa243-4.8-2.patch. > The text of the advisory leads me to believe that it should be there, so > it seems to be missing. The text

[Xen-devel] [distros-debian-jessie test] 72458: tolerable all pass

flight 72458 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72458/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail like 72438

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

flight 116224 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/116224/ 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. 116214 Tests which did

Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver

ping On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote: Hi, all! Foreword This RFC is aimed to introduce support of para-virtualized sound frontend driver for Xen [1] and gather opinions from the relevant communities (ALSA, Xen). It implements the protocol from [2] with the