flight 116737 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116737/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken in 116653
Tests
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> First implementation of the cpufreq driver has been
> written with x86 in mind. This patch makes possible
> the cpufreq driver be working on both x86 and arm
> architectures.
>
> This is a rebased version of the ori
On Thu, 9 Nov 2017, Wei Liu wrote:
> On Thu, Nov 09, 2017 at 07:09:57PM +0200, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > CPU frequencies are in kHz. So, correct displayed text.
> >
> > Signed-off-by: Oleksandr Tyshchenko
> > CC: Ian Jackson
> > CC: Wei Liu
> > CC: Ste
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> ACPI-specific parts are moved under appropriate ifdefs.
> Now pmstat functions can be used in ARM platform.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-1
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> This settings is not needed for some architectures.
> So make it to be configurable and use it for x86
> architecture.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-d
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/h
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/h
flight 116733 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116733/
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. 115539
Tests which are failing
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
>
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/h
flight 116764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116764/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116731 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 116625
build-armhf-pvops
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
> This is follow-up to our conversation during community call.
> You asked me to send OP-TEE mediator as a patch, so we can
> discuss it in the mailing list. So, there it is. I squashed
> two patches into one and skipped patches that we already
> discus
This run is configured for baseline tests only.
flight 72506 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 11 examine-serial/
On Thu, 30 Nov 2017, Jan Beulich wrote:
> Dropping the lock before returning from grant_map_exists() means handing
> possibly stale information back to the caller. Return back the pointer
> to the active entry instead, for the caller to release the lock once
> done.
>
> Signed-off-by: Jan Beulich
flight 116757 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116757/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Thu, 30 Nov 2017, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A simi
Hi Paul,
> That's QEMU failing to start which is, most likely, an incompatibility
between libxl and the QEMU command line. With any luck you should have a log
> file called /var/log/xen/qemu-dm-.log which in which QEMU
should say what it is unhappy about.
On checking the suggested log there is t
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 116747 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116747/
Failures :-/
Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
guests looking at IF flag directly will always see it set, resulting
in 'ud2'.
Introduce SAVE_F
flight 116728 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 1165
flight 116732 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116732/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116698
test-armhf-armhf-libvirt-raw 13 saveresto
On 28/11/17 08:32, Jan Beulich wrote:
On 26.10.17 at 19:03, wrote:
>> * invvpid has a 128-bit memory operand but we only require the VPID value
>> which lies in the lower 64 bits.
> The memory operand (wrongly) isn't being read at all - I don't
> understand the above bullet point for that r
On 01/12/17 16:55, Jan Beulich wrote:
Julien Grall 12/01/17 5:14 PM >>>
>> On 30/11/17 14:28, Jan Beulich wrote:
>> On 28.11.17 at 15:05, wrote:
A call to handle_hvm_io_completion() is needed for completing I/O
that requires external emulation. Such completion should be request
On Fri, Dec 1, 2017 at 8:57 AM, Boris Ostrovsky
wrote:
> On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
>> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
>> wrote:
>>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro th
flight 116752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR.
vs. 116673
T
On Fr, 01.12.17 12:04, Olaf Hering (o...@aepfle.de) wrote:
> Am Fri, 1 Dec 2017 10:21:46 +
> schrieb Wei Liu :
>
> > In Olaf's case, he cares about knowing whether the domain runs the
> > controlling toolstack, he doesn't care about if it is the hardware
> > domain or not, so my conclusion wa
On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
> wrote:
>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
>> eflags using 'pushfq' instruction when testing f
>>> Julien Grall 12/01/17 5:14 PM >>>
>On 30/11/17 14:28, Jan Beulich wrote:
> On 28.11.17 at 15:05, wrote:
>>> A call to handle_hvm_io_completion() is needed for completing I/O
>>> that requires external emulation. Such completion should be requested when
>>> hvm_vcpu_io_need_completion() re
>>> Wei Liu 12/01/17 1:30 PM >>>
>On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 13:15, wrote:
>> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >> >>> On 01.12.17 at 12:48, wrote:
>> >> > Suppose at one point we split hardware domain and co
flight 116725 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116725/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 116531
Tests which did not s
On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
wrote:
> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
> eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
> guests looking at IF flag direc
Hi Anthony,
On 29/11/17 15:06, Anthony PERARD wrote:
On Wed, Nov 29, 2017 at 12:28:39PM +, Julien Grall wrote:
+ Stefano
On 11/27/2017 03:00 PM, Anthony PERARD wrote:
Hi Julien,
Hi Anthony,
Can I get a release-ack for this patch?
This fix local live migration of HVM guest when the d
On 11/30/2017 8:46 AM, Jan Beulich wrote:
On 30.11.17 at 15:15, wrote:
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device.
Hi Jan,
On 01/12/17 11:21, Jan Beulich wrote:
On 30.11.17 at 19:54, wrote:
On 27/11/17 14:41, Jan Beulich wrote:
On 27.11.17 at 14:02, wrote:
Xen 4.8 and later virtualises CPUID Faulting support for guests. However,
the
value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, m
Hi,
On 30/11/17 14:28, Jan Beulich wrote:
On 28.11.17 at 15:05, wrote:
A call to handle_hvm_io_completion() is needed for completing I/O
that requires external emulation. Such completion should be requested when
hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
completed.
Hi,
On 01/12/17 15:23, Ian Jackson wrote:
Julien Grall writes ("Commit moratorium for branching Xen 4.10"):
Xen tree is going to branch at RC7. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another annou
On Fri, Dec 01, 2017 at 04:49:01PM +0100, Olaf Hering wrote:
> On Fri, Dec 01, Wei Liu wrote:
>
> > What information do you need? For a moment let's skip using the fuzzy
> > "Dom0" term and try to be precise. Like "I would like to know if that
> > domain has access to all hardware" or something el
On Fri, Dec 01, Wei Liu wrote:
> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.
That depends on the .service files. This is the list of openSUSE T
Hi,
On 30/11/17 14:32, Jan Beulich wrote:
> Dropping the lock before returning from grant_map_exists() means handing
> possibly stale information back to the caller. Return back the pointer
> to the active entry instead, for the caller to release the lock once
> done.
I don't know enough about gr
Hi,
On 30/11/17 14:31, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A s
On Fri, Dec 01, 2017 at 03:20:06PM +, Ian Jackson wrote:
> The old instructions were obsolete. Here are the details I used when
> branching for 4.10.
>
> CC: Julien Grall
> CC: Wei Liu
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-dev
Julien Grall writes ("Commit moratorium for branching Xen 4.10"):
> Xen tree is going to branch at RC7. I don't want to branch when
> master != staging, so please avoid committing new patches to staging now
> to let master catch up with staging. Another announcement will be made
> when the moratori
The old instructions were obsolete. Here are the details I used when
branching for 4.10.
CC: Julien Grall
CC: Wei Liu
Signed-off-by: Ian Jackson
---
docs/process/release-checklist.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/docs/process/release-checklist.txt
Instead of locating the RSDP table below 1MB put it just below 4GB
like the rest of the ACPI tables in case of PVH guests. This will
avoid punching more holes than necessary into the memory map.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
tools/libxc/xc_dom_hvmloader.c | 2 +-
tools/libx
On Wed, Nov 29, 2017 at 03:13:16PM +0100, Juergen Gross wrote:
> Instead of locating the RSDP table below 1MB put it just below 4GB
> like the rest of the ACPI tables in case of PVH guests. This will
> avoid punching more holes than necessary into the memory map.
>
> Signed-off-by: Juergen Gross
flight 116722 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116722/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 116642
test-amd64-amd64-xl-qemuu-ws16-amd64
On Fri, Dec 01, 2017 at 01:38:48PM +0100, Olaf Hering wrote:
> Am Fri, 1 Dec 2017 12:29:24 +
> schrieb Wei Liu :
>
> > But Olaf needs to know if some of the services like xenconsoled or
> > xenstored should be started, and if some of the special file systems
> > should be mounted, right? Those
Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :
> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibilit
On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 13:15, wrote:
> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
> >> >>> On 01.12.17 at 12:48, wrote:
> >> > Suppose at one point we split hardware domain and control domain, which
> >> > one will you
>>> On 30.11.17 at 20:32, wrote:
> List,
> this XSA-245 appears in the xen-devel ML, but unlike XSA-246,247 it never
> appears in the git logs.
> Was it ever committed?
Yes. Did you perhaps scan for "XSA-245" in the description, which
may have been omitted in this case?
Jan
__
Due to a recent FreeBSD change the default output directory of the release
targets is changed to the object directory instead of the source
directory. Use WITHOUT_AUTO_OBJ to restore previous behavior. This is
harmless if used with previous versions, it will be ignored.
Signed-off-by: Roger Pau Mo
>>> On 01.12.17 at 13:15, wrote:
> On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 12:48, wrote:
>> > Suppose at one point we split hardware domain and control domain, which
>> > one will you call Dom0? Which one will get the flag?
>>
>> There can only be one h
When the FreeBSD installer is booted on the godello{0/1} boxes it
receives spurious key strokes. This doesn't happen so far when booted
from disk, or with any other boxes.
In order to cope with this remove the loader timeout on the install
image. Note that failure to boot will still drop the loade
The Mass osstest instance has a more diverse list of hardware disk
controllers, so expand the list in order to include all the possible
disk drivers.
For the record, this list can be found at:
usr.sbin/bsdconfig/share/device.subr
In the FreeBSD source tree.
Signed-off-by: Roger Pau Monné
---
Hello,
This are again the remaining non-acked patches of the FreeBSD osstest
series. The two patches sent with this cover letter fix two issues
found on the Mass colo.
Patch 17 fixes an issue where the FreeBSD installer bootloader
receives random keystrokes on the console, thus aborting the autom
On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 12:48, wrote:
> > Suppose at one point we split hardware domain and control domain, which
> > one will you call Dom0? Which one will get the flag?
>
> There can only be one hardware domain, which will continue to
>
On Thu, Nov 09, 2017 at 11:13:41AM +, Roger Pau Monne wrote:
> Use autodetect only.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
>>> On 01.12.17 at 12:48, wrote:
> Suppose at one point we split hardware domain and control domain, which
> one will you call Dom0? Which one will get the flag?
There can only be one hardware domain, which will continue to
be the one getting XENFEAT_dom0. There could be any number
of control dom
On Fri, Dec 01, 2017 at 04:39:30AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 11:21, wrote:
> > On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.17 at 09:23, wrote:
> >> > On Wed, Nov 29, Jan Beulich wrote:
> >> >
> >> >> Ah, I see. But then still I don't see wh
>>> On 01.12.17 at 11:21, wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23, wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> >
>> >> Ah, I see. But then still I don't see why at least on half way
>> >> recent Xen /sys/hypervisor/properties/featur
>>> On 30.11.17 at 19:54, wrote:
> On 27/11/17 14:41, Jan Beulich wrote:
> On 27.11.17 at 14:02, wrote:
>>> Xen 4.8 and later virtualises CPUID Faulting support for guests. However,
> the
>>> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
>>> that the current cpu
This is not a normal way to carry on. Far too much like hard work.
Recommend make-flight or cs-adjust-flight new: instead.
CC: Julien Grall
Signed-off-by: Ian Jackson
---
README | 49 +
1 file changed, 17 insertions(+), 32 deletions(-)
diff --gi
In 497b2c6c933d13a05b01c6a654ce470be16dd78a
cs-adjust-flight: Rework runvar-build-set new value handling
the interpretation of this parameter was changed completely, but the
synopsis was not updated and thus became wrong.
Signed-off-by: Ian Jackson
---
cs-adjust-flight | 9 +
1 file ch
On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
> On 30/11/17 22:03, Daniel Kiper wrote:
> > On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> >> This patch series adds support for booting Linux as PVH guest.
> >>
> >> Similar to i386/xen and x86_64/xen platforms the n
Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.
I think this is not entirely accurate. Rig
On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
> >>> On 30.11.17 at 09:23, wrote:
> > On Wed, Nov 29, Jan Beulich wrote:
> >
> >> Ah, I see. But then still I don't see why at least on half way
> >> recent Xen /sys/hypervisor/properties/features wouldn't have
> >> the information you
flight 72505 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72505/
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 72489
test-armhf-armhf-
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Alex Braunegg
> Sent: 01 December 2017 02:01
> To: xen-devel@lists.xenproject.org
> Subject: [Xen-devel] unable to start VM after xen upgrade to 4.8.2
>
> Hi all,
>
> I recently updated f
flight 116719 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116719/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken in 116653
test-a
On 30/11/2017 19:23, Maran Wilson wrote:
> Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
> should use the fw_cfg interface to read the e820 memory map data and put
> it into the zeropage? Basically, keeping the patch very much like it
> already is, just extracting the e820
71 matches
Mail list logo
