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
follow
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 no
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
test-armhf-armhf-
>>> 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 has xsa243-{4.8-1
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 mailing list
Xen-devel@lists.xen.org
https://lists.
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
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 hvm_sav
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,
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 a
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. Please consider for
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: Juerge
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
>>> 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 )
{
switch ( ctxt->msr[i].ind
>>> 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 spec-compliant stream, so t
>>> 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 hvm_save_descriptor with length for
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 sheet might be
> useful fo
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 prob
>>> 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 you looked at a cou
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 guest.
>
> This is
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 step-by-step.
If community agr
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
test-amd64-amd64-xl
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 -
> arch/x86/include/asm
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
>>
>> Thank you for your comments!
>>
>>>
>>> On 14/11/17
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 n
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 fa
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
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
> ---
> This i
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 9ba6783e47db71379c5120039b878f
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 ru
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 CPUFreq on x86 have own logic? Do
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 blo
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
te
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 blocking,
including tests which could
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
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, Oleksandr Tyshchenko wrote:
>
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
>> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualiza
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 did it in a following way:
>> - wire up to UA
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 w
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 omap2plus_defconfig might ups
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 32-b
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
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 git://xenbits.xen.org/qemu-xen-traditional
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
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
test-amd
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 are
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
test-amd64-i386
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 are
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 gues
48 matches
Mail list logo
