flight 96510 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
flight 96511 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 95631
Regressions which
This run is configured for baseline tests only.
flight 66485 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66485/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf
flight 96505 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96505/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail in 96483 pass in 96505
test-armhf-armhf-xl-arndale 6 xe
This run is configured for baseline tests only.
flight 66481 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66481/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops
flight 96502 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
This run is configured for baseline tests only.
flight 66482 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs
David Vrabel writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re:
[PATCH 0/2] xtf: add launcher (+1 bugfix)"):
> On 20/06/16 18:03, Ian Jackson wrote:
> > Hopefully we can find one that Andrew likes and that's acceptable to
> > the committers.
> >
> > I suggest
> > xen-microvm-test
flight 96501 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96501/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95995
Tests which did not succeed, but a
If a VMLAUNCH/VMRESUME fails due to invalid control or host state, dump the
VMCS before crashing the domain.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmcs.c| 5 +
xen/include/asm-x86/hvm/vmx/vmcs.h | 4
2 files
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm
testid debian-hvm-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
Tr
On Thu, Jun 30, 2016 at 12:41 PM, Corneliu ZUZU wrote:
> A VM_EVENT_FLAG_VCPU_PAUSED flag in a vm-event response should only be treated
> as informative that the toolstack user wants the vm-event subsystem to unpause
> the target vCPU, but not be relied upon to decide if the target vCPU is
> actu
On 01/07/16 17:10, Jan Beulich wrote:
On 01.07.16 at 17:38, wrote:
>> As for interleaving inside the asm statement itself, we already have
>> precedent for that with the HAVE_GAS_* predicates. It would make the
>> patch rather larger, but might end up looking cleaner. It is probably
>> also
This run is configured for baseline tests only.
flight 66487 qemu-upstream-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66487/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pv
On Fri, Jul 1, 2016 at 9:55 AM, Jan Beulich wrote:
On 01.07.16 at 17:32, wrote:
>> On Jul 1, 2016 01:17, "Corneliu ZUZU" wrote:
>>>
>>> Fix vm-event section of MAINTAINERS file.
>>>
>>> Signed-off-by: Corneliu ZUZU
>>> ---
>>> MAINTAINERS | 8 ++--
>>> 1 file changed, 6 insertions(+),
On 01/07/16 17:18, Jan Beulich wrote:
On 24.06.16 at 12:28, wrote:
>> ... as a means to replace all HVMOP_* which a domain can't issue on
>> itself (i.e. intended for use by only the control domain or device
>> model).
>>
>> Signed-off-by: Jan Beulich
>> Reviewed-by: Wei Liu
> On the x86 si
flight 96507 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 94748
build-amd64
>>> On 24.06.16 at 12:28, wrote:
> ... as a means to replace all HVMOP_* which a domain can't issue on
> itself (i.e. intended for use by only the control domain or device
> model).
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
On the x86 side I'm just lacking feedback for this patch.
>>> On 01.07.16 at 17:38, wrote:
> As for interleaving inside the asm statement itself, we already have
> precedent for that with the HAVE_GAS_* predicates. It would make the
> patch rather larger, but might end up looking cleaner. It is probably
> also worth switching to named parameters to red
>>> On 01.07.16 at 17:32, wrote:
> On Jul 1, 2016 01:17, "Corneliu ZUZU" wrote:
>>
>> Fix vm-event section of MAINTAINERS file.
>>
>> Signed-off-by: Corneliu ZUZU
>> ---
>> MAINTAINERS | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> On 01.07.16 at 17:38, wrote:
> On 01/07/16 16:01, Jan Beulich wrote:
>> TBD: Do we want to abstract the pattern
>> asm ( "...; set %" : "=" (var) ... )
>> matching
>> asm ( "..." : "=@cc" (var) ... )
>> via some macro? While this would eliminate many (all?) of the
>> conditionals add
On 01/07/16 16:01, Jan Beulich wrote:
> ..., rendering affected code more efficient and smaller.
Ooh - this is a neat feature.
>
> Note that in atomic.h this at once does away with the redundant output
> and input specifications of the memory location touched.
>
> Signed-off-by: Jan Beulich
> --
On Jul 1, 2016 01:17, "Corneliu ZUZU" wrote:
>
> Fix vm-event section of MAINTAINERS file.
>
> Signed-off-by: Corneliu ZUZU
> ---
> MAINTAINERS | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e91140f..7bff878 100644
> --- a/MAINT
Hi Boris,
On 01/07/16 15:42, Boris Ostrovsky wrote:
On 07/01/2016 06:18 AM, Julien Grall wrote:
On 01/07/16 08:58, Shannon Zhao wrote:
On 2016/6/30 2:58, Boris Ostrovsky wrote:
git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
[...]
Looks like Boris is going to use libxl__dom_load_acp
flight 96498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
..., rendering affected code more efficient and smaller.
Note that in atomic.h this at once does away with the redundant output
and input specifications of the memory location touched.
Signed-off-by: Jan Beulich
---
TBD: Do we want to abstract the pattern
asm ( "...; set %" : "=" (var) .
On 07/01/2016 06:18 AM, Julien Grall wrote:
> Hi Shannon,
>
> On 01/07/16 08:58, Shannon Zhao wrote:
>> On 2016/6/30 2:58, Boris Ostrovsky wrote:
>>> git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
>> Hi Boris,
>>
>> Thanks a lot!
>> While I found there is a compiling problem of the last patc
flight 96483 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96483/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 96296
test-armhf-armhf-xl-rtds
This run is configured for baseline tests only.
flight 66480 xen-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66480/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops
>>> On 01.07.16 at 14:06, wrote:
> "Jan Beulich" writes:
>
> On 29.06.16 at 18:27, wrote:
>>> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
To explain better what I'm trying to suggest here please take a look at
the attached patch. If we can guarantee long term that ACPI id always
>>
flight 96480 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 94856
test-amd64
"Jan Beulich" writes:
On 29.06.16 at 18:27, wrote:
>> On 29/06/16 17:19, Vitaly Kuznetsov wrote:
>>> To explain better what I'm trying to suggest here please take a look at
>>> the attached patch. If we can guarantee long term that ACPI id always
>>> equals to Xen's idea of vCPU id this is
On 07/01/16 12:44, Corneliu ZUZU wrote:
> Fix vm-event section of MAINTAINERS file: add back files x86/hvm/monitor.c,
> asm-x86/hvm/monitor.h, x86/monitor.c, x86/vm_event.c and sort entries
> alphabetically.
>
> Culprits which got MAINTAINERS out-of-sync:
> c/s ca63cee: "monitor: Rename hvm/event
Hi Shannon,
On 01/07/16 08:58, Shannon Zhao wrote:
On 2016/6/30 2:58, Boris Ostrovsky wrote:
git://oss.oracle.com/git/bostrovs/xen.git:acpi_v1_wip
Hi Boris,
Thanks a lot!
While I found there is a compiling problem of the last patch.
undefined reference to `libxl__dom_load_acpi'
collect2: err
flight 96487 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
Fix vm-event section of MAINTAINERS file: add back files x86/hvm/monitor.c,
asm-x86/hvm/monitor.h, x86/monitor.c, x86/vm_event.c and sort entries
alphabetically.
Culprits which got MAINTAINERS out-of-sync:
c/s ca63cee: "monitor: Rename hvm/event to hvm/monitor":
- added x86/hvm/monitor.c & asm
Instead of a Linux kernel based implementation use one from freeBSD.
Signed-off-by: Juergen Gross
---
I'm not sure about coding style here: should I keep (more or less) the
one from freeBSD, or is the Xen style preferred?
---
blkfront.c|4 -
include/lib-gpl.h |7 +-
lib/printf.c
"make cscope" doesn't like symbolic link include/mini-os->. as it
leads to a file system recursion. Repair that by not following links
when searching the sources.
Signed-off-by: Juergen Gross
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
ind
David Vrabel writes:
> On 29/06/16 10:16, Vitaly Kuznetsov wrote:
>> David Vrabel writes:
>>
>>> On 28/06/16 17:47, Vitaly Kuznetsov wrote:
It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and
>>> On 01.07.16 at 11:12, wrote:
> Anyway, so you want me to sort those strictly alphabetically, i.e. the
> list would finally look like:
>
> F:tools/tests/xen-access
> F:xen/arch/*/monitor.c
> F:xen/arch/*/vm_event.c
> F:xen/arch/x86/hvm/monitor.c
> F:xen/common/mem_access.c
On 7/1/2016 11:02 AM, Jan Beulich wrote:
On 01.07.16 at 09:40, wrote:
On 7/1/2016 10:27 AM, Jan Beulich wrote:
On 01.07.16 at 09:15, wrote:
Fix vm-event section of MAINTAINERS file.
Would be nice to mention here which commit(s) caused these to go
out of sync with the actual code.
Why?
Wel
>>> On 01.07.16 at 09:40, wrote:
> On 7/1/2016 10:27 AM, Jan Beulich wrote:
> On 01.07.16 at 09:15, wrote:
>>> Fix vm-event section of MAINTAINERS file.
>> Would be nice to mention here which commit(s) caused these to go
>> out of sync with the actual code.
>
> Why?
Well, I already said so
On 2016/6/30 2:58, Boris Ostrovsky wrote:
> On 06/28/2016 09:41 AM, Boris Ostrovsky wrote:
>> > On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>>> >> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>> On 06/27/2016 06:29 AM, Julien Grall wrote:
> (CC Boris and Doug)
>
> H
>>> On 30.06.16 at 07:50, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -243,6 +243,17 @@ def crunch_numbers(state):
> # AMD K6-2+ and K6-III processors shipped with 3DNow+, beyond the
> # standard 3DNow in the earlier K6 processors.
> _3DNOW:
On 06/30/16 21:43, Corneliu ZUZU wrote:
> For readability:
>
> * Add function arch_monitor_write_data (in x86/monitor.c) and separate
> handling
> of monitor_write_data there (previously done directly in hvm_do_resume).
>
> * Add function write_ctrlreg_adjust_traps (in x86/monitor.c) and relocat
>>> On 15.06.16 at 11:50, wrote:
> 1: x86/time: adjust local system time initialization
> 2: x86: also generate assembler usable equates for synthesized features
> 3: x86/time: introduce and use rdtsc_ordered()
> 4: x86/time: calibrate TSC against platform timer
> 5: x86/time: correctly honor late
On 7/1/2016 10:31 AM, Jan Beulich wrote:
On 01.07.16 at 09:02, wrote:
On 7/1/2016 9:56 AM, Razvan Cojocaru wrote:
On 06/30/16 21:47, Corneliu ZUZU wrote:
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#i
On 7/1/2016 10:27 AM, Jan Beulich wrote:
On 01.07.16 at 09:15, wrote:
Fix vm-event section of MAINTAINERS file.
Would be nice to mention here which commit(s) caused these to go
out of sync with the actual code.
Why?
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -402,10 +402,14 @@ M:Razv
flight 96491 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96491/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
>>> On 01.07.16 at 09:02, wrote:
> On 7/1/2016 9:56 AM, Razvan Cojocaru wrote:
>> On 06/30/16 21:47, Corneliu ZUZU wrote:
>>> --- a/xen/arch/x86/hvm/monitor.c
>>> +++ b/xen/arch/x86/hvm/monitor.c
>>> @@ -26,6 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>
>>> On 01.07.16 at 09:15, wrote:
> Fix vm-event section of MAINTAINERS file.
Would be nice to mention here which commit(s) caused these to go
out of sync with the actual code.
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -402,10 +402,14 @@ M: Razvan Cojocaru
> M: Tamas K Lengyel
> S:
>>> On 30.06.16 at 17:13, wrote:
> On Thu, Jun 30, 2016 at 10:01:18AM -0400, Daniel De Graaf wrote:
>> On 06/30/2016 09:45 AM, Konrad Rzeszutek Wilk wrote:
>> > On Wed, Jun 29, 2016 at 11:09:01AM -0400, Daniel De Graaf wrote:
>> > > --- a/xen/xsm/xsm_core.c
>> > > +++ b/xen/xsm/xsm_core.c
>> > > @
On 7/1/2016 10:15 AM, Corneliu ZUZU wrote:
Fix vm-event section of MAINTAINERS file.
Signed-off-by: Corneliu ZUZU
---
MAINTAINERS | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e91140f..7bff878 100644
--- a/MAINTAINERS
+++ b/MAINTA
On 06/30/16 21:41, Corneliu ZUZU wrote:
> A VM_EVENT_FLAG_VCPU_PAUSED flag in a vm-event response should only be treated
> as informative that the toolstack user wants the vm-event subsystem to unpause
> the target vCPU, but not be relied upon to decide if the target vCPU is
> actually
> paused.
>
Fix vm-event section of MAINTAINERS file.
Signed-off-by: Corneliu ZUZU
---
MAINTAINERS | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e91140f..7bff878 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -402,10 +402,14 @@ M:Razvan Co
On 7/1/2016 9:56 AM, Razvan Cojocaru wrote:
On 06/30/16 21:47, Corneliu ZUZU wrote:
Move xen/paging.h #include from hvm/monitor.h to hvm/monitor.c (include strictly
where needed) and also change to asm/paging.h (include strictly what's needed).
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/h
On 06/30/16 21:46, Corneliu ZUZU wrote:
> VM_EVENT_REASON_MOV_TO_MSR is X86-specific, surround w/ #ifdef accordingly.
>
> Signed-off-by: Corneliu ZUZU
> ---
> xen/common/vm_event.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Razvan Cojocaru
Thanks,
Razvan
__
On 07/01/16 09:56, Corneliu ZUZU wrote:
> On 7/1/2016 9:47 AM, Razvan Cojocaru wrote:
>> On 06/30/16 21:45, Corneliu ZUZU wrote:
>>> The arch_vm_event structure is dynamically allocated and freed @
>>> vm_event_cleanup_domain. This cleanup is triggered e.g. when the
>>> toolstack user
>>> disables
On 7/1/2016 9:53 AM, Razvan Cojocaru wrote:
On 06/30/16 21:44, Corneliu ZUZU wrote:
After trapping a control-register write vm-event and -until- deciding if that
write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual write,
there cannot and should not be another trapped contro
59 matches
Mail list logo
