flight 114528 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114528/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 6 xen-install fail REGR. vs. 114500
Tests which did not succeed,
On Fri, 2017-10-13 at 16:16 +0100, Andrew Cooper wrote:
> On 13/10/17 13:35, Sergey Dyasli wrote:
> > @@ -210,6 +375,255 @@ struct msr_domain_policy
> > bool available; /* This MSR is non-architectural */
> > bool cpuid_faulting;
> > } plaform_info;
> > +
> > +/* 0x04
On Fri, 2017-10-13 at 16:25 +0100, Andrew Cooper wrote:
> On 13/10/17 13:35, Sergey Dyasli wrote:
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 205b4cb685..7e6b15f8d7 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -928,9 +928,8 @@ const
On Fri, Oct 13, 2017 at 10:45 PM, Boris Ostrovsky
wrote:
> On 10/13/2017 02:37 PM, Arnd Bergmann wrote:
>> The x86 platform operations are fairly isolated, so we can
>> change them from using timespec to timespec64. I checked that
>> All the users and callers are safe, and there is only one
>> cri
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.
Introduced a new format string "PRIu_xen_pfn" whic
On 13 October 2017 at 20:36, Jan Beulich wrote:
On 13.10.17 at 16:35, wrote:
>> Hi Jan,
>>
>> On 13/10/17 15:03, Jan Beulich wrote:
>> On 13.10.17 at 15:03, wrote:
On 13/10/17 13:32, Jan Beulich wrote:
On 13.10.17 at 14:19, wrote:
>> On 13/10/17 13:08, Jan Beulich wro
On 15/10/17 20:45, osstest service owner wrote:
> flight 114505 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/114505/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-2 48 xtf/tes
>>> On 13.10.17 at 18:07, wrote:
> On 10/13/17 2:40 AM, Jan Beulich wrote:
> On 12.10.17 at 22:56, wrote:
>>> On 12/10/2017 21:50, Doug Goldstein wrote:
From: David Esler
The send_chr function sends an entire C-string and not one character and
doesn't necessarily just sen
Otherwise,
f942a9b4a12081d5f9a4679d06e88cb5d503396e
xentoolcore_restrict_all: "Implement" for xenstore
breaks the build of the tools inside rumprun.
Signed-off-by: Ian Jackson
CC: Wei Liu
---
tools/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Makefile b
Hi Bhupinder,
On 16/10/17 10:02, Bhupinder Thakur wrote:
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
However, xenstore reads this value as a decimal value and tries to map the
wrong address an
>>> On 16.10.17 at 11:02, wrote:
> static int console_create_ring(struct console *con)
> {
> - int err, remote_port, ring_ref, rc;
> + int err, remote_port, rc;
> + xen_pfn_t ring_ref;
> char *type, path[PATH_MAX];
> struct domain *dom = con->d;
>
> err = xs_gathe
>>> On 16.10.17 at 12:18, wrote:
> On 16/10/17 10:02, Bhupinder Thakur wrote:
>> --- a/tools/console/daemon/io.c
>> +++ b/tools/console/daemon/io.c
>> @@ -80,6 +80,7 @@ static unsigned int current_array_size;
>> static unsigned int nr_fds;
>>
>> #define ROUNDUP(_x,_w) (((unsigned long)(_x)+
On Mon, Oct 16, 2017 at 11:17:12AM +0100, Ian Jackson wrote:
> Otherwise,
> f942a9b4a12081d5f9a4679d06e88cb5d503396e
> xentoolcore_restrict_all: "Implement" for xenstore
> breaks the build of the tools inside rumprun.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
This run is configured for baseline tests only.
flight 72239 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-521 xtf/test-hvm32-
Ross Lagerwall writes ("[PATCH v1 1/2] tools/libs/evtchn: Add support for
restricting a handle"):
> +/*
> + * Restrict this file descriptor so that it can only be used to bind
> + * new interdomain events from one domain.
Can it be used to bind other kinds of events ? The phrasing is
ambigous.
Ross Lagerwall writes ("[PATCH v2 2/2] xentoolcore_restrict_all: Implement for
libxenevtchn"):
> Signed-off-by: Ross Lagerwall
...
> int osdep_evtchn_open(xenevtchn_handle *xce);
> diff --git a/tools/libs/toolcore/include/xentoolcore.h
> b/tools/libs/toolcore/include/xentoolcore.h
> index be6c5
On 10/16/2017 11:53 AM, Ian Jackson wrote:
Ross Lagerwall writes ("[PATCH v1 1/2] tools/libs/evtchn: Add support for
restricting a handle"):
+/*
+ * Restrict this file descriptor so that it can only be used to bind
+ * new interdomain events from one domain.
Can it be used to bind other kinds
On Mon, Oct 16, 2017 at 12:23:12PM +0100, Ian Jackson wrote:
> Otherwise,
> f942a9b4a12081d5f9a4679d06e88cb5d503396e
> xentoolcore_restrict_all: "Implement" for xenstore
> breaks the build of the tools inside rumprun.
>
> toolcore is in libs, so we need to add the CONFIG_RUMP special case to
>
Otherwise,
f942a9b4a12081d5f9a4679d06e88cb5d503396e
xentoolcore_restrict_all: "Implement" for xenstore
breaks the build of the tools inside rumprun.
toolcore is in libs, so we need to add the CONFIG_RUMP special case to
tools/libs/Makefile and add toolcore there.
Signed-off-by: Ian Jackson
C
On 16/10/17 11:30, Wei Liu wrote:
On Mon, Oct 16, 2017 at 11:17:12AM +0100, Ian Jackson wrote:
Otherwise,
f942a9b4a12081d5f9a4679d06e88cb5d503396e
xentoolcore_restrict_all: "Implement" for xenstore
breaks the build of the tools inside rumprun.
Signed-off-by: Ian Jackson
Acked-by: Wei
Ross Lagerwall writes ("Re: [PATCH v1 1/2] tools/libs/evtchn: Add support for
restricting a handle"):
> No. As far as I can see, it can only be used to bind new interdomain
> events, not other events.
OK, good, thanks.
> This entire file (including the description) is copied directly from
> Li
flight 114533 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken in 114501
build-armhf-pvops
On 11/10/17 20:01, Volodymyr Babchuk wrote:
Hello all,
Hi Volodymyr,
I want to present TEE mediator, that was discussed earlier ([1]).
I selected design with built-in mediators. This is easiest way,
it removes many questions, it is easy to implement and maintain
(at least I hope so).
We
flight 72240 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72240/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a
build-arm64-pvops
On 16/10/2017 10:11, Arnd Bergmann wrote:
> Thanks!
>
> Since you've looked at it overall, do you have an opinion on the question
> how to fix the PV interface to deal with the pvclock_wall_clock overflow?
It has to be done separately for each hypervisor.
In KVM, for example, it is probably best
On 10/16/2017 12:29 PM, Ian Jackson wrote:
Ross Lagerwall writes ("Re: [PATCH v1 1/2] tools/libs/evtchn: Add support for
restricting a handle"):
No. As far as I can see, it can only be used to bind new interdomain
events, not other events.
OK, good, thanks.
This entire file (including the d
On Mon, Oct 16, 2017 at 2:08 PM, Paolo Bonzini wrote:
> On 16/10/2017 10:11, Arnd Bergmann wrote:
>> Thanks!
>>
>> Since you've looked at it overall, do you have an opinion on the question
>> how to fix the PV interface to deal with the pvclock_wall_clock overflow?
>
> It has to be done separately
On 16/10/2017 14:16, Arnd Bergmann wrote:
> On Mon, Oct 16, 2017 at 2:08 PM, Paolo Bonzini wrote:
>> On 16/10/2017 10:11, Arnd Bergmann wrote:
>>> Thanks!
>>>
>>> Since you've looked at it overall, do you have an opinion on the question
>>> how to fix the PV interface to deal with the pvclock_wall
Since the emulator acts on the live hardware registers, we need to
prevent the compiler from using them e.g. for inlined memcpy() /
memset() (as gcc7 does). We can't, however, set this from the command
line, as otherwise the 64-bit build would face issues with functions
returning floating point val
On 16/10/17 13:32, Jan Beulich wrote:
> Since the emulator acts on the live hardware registers, we need to
> prevent the compiler from using them e.g. for inlined memcpy() /
> memset() (as gcc7 does). We can't, however, set this from the command
> line, as otherwise the 64-bit build would face issu
>>> On 16.10.17 at 14:37, wrote:
> On 16/10/17 13:32, Jan Beulich wrote:
>> Since the emulator acts on the live hardware registers, we need to
>> prevent the compiler from using them e.g. for inlined memcpy() /
>> memset() (as gcc7 does). We can't, however, set this from the command
>> line, as ot
>>> On 16.10.17 at 05:04, wrote:
> This patch implements set value flow for MBA including its callback
> function and domctl interface.
>
> Signed-off-by: Yi Sun
Reviewed-by: Jan Beulich
> v8:
> - restore some unnecessary changes in 'cat_check_cbm'.
> (suggested by Jan Beulich)
Thi
>>> On 13.10.17 at 22:42, wrote:
> @@ -4586,6 +4620,107 @@ static int do_altp2m_op(
> return rc;
> }
>
> +DEFINE_XEN_GUEST_HANDLE(compat_hvm_altp2m_op_t);
> +
> +#ifndef CHECK_hvm_altp2m_op
> +#define CHECK_hvm_altp2m_op \
> +CHECK_SIZE_(struct, hvm_altp2m_op); \
> +CHECK_FIELD_(st
Hi Volodymyr,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediaor" is a such entity.
s/mediaor/mediator/
This is how it
>>> On 13.10.17 at 07:10, wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -168,11 +168,13 @@ void hvm_gsi_deassert(struct domain *d, unsigned int
> gsi)
> spin_unlock(&d->arch.hvm_domain.irq_lock);
> }
>
> -void hvm_isa_irq_assert(
> -struct domain *d, unsign
RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
drivers use a minimum value of 0.
When set MTU to 0~67 with xen_net{front|back} driver, the network
will become unreachable immediately, the guest can no longer be pinged.
xen_net{front|back} should not allow the user to set thi
flight 114538 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114538/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-2 48 xtf/test-hvm64-lbr-tsx-vmentry fail in 114505 pass
in 114538
test-armhf-armhf-xl-
On Fri, Oct 13, 2017 at 06:32:18PM +0100, Andrew Cooper wrote:
> c/s 4d69b3495 "Introduce migration precopy policy" uses bogus reasoning to
> justify passing precopy_stats by value.
>
> Under no circumstances can the precopy callback ever be executing in a
> separate address space.
>
The callbac
On 16/10/17 14:40, Wei Liu wrote:
> On Fri, Oct 13, 2017 at 06:32:18PM +0100, Andrew Cooper wrote:
>> c/s 4d69b3495 "Introduce migration precopy policy" uses bogus reasoning to
>> justify passing precopy_stats by value.
>>
>> Under no circumstances can the precopy callback ever be executing in a
>>
>>> On 12.10.17 at 18:25, wrote:
> @@ -402,14 +469,56 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
> rc = do_memory_op(cmd, nat.hnd);
> if ( rc < 0 )
> {
> -if ( rc == -ENOBUFS && op == XENMEM_get_vnumainfo )
> +
On 16/10/17 08:42, Sergey Dyasli wrote:
> On Fri, 2017-10-13 at 16:16 +0100, Andrew Cooper wrote:
>> On 13/10/17 13:35, Sergey Dyasli wrote:
>>> @@ -210,6 +375,255 @@ struct msr_domain_policy
>>> bool available; /* This MSR is non-architectural */
>>> bool cpuid_faulting;
>>>
Hi Volodymyr,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcomient OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Tho
Hope this can placate coverity.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Julien Grall
---
tools/libxl/libxl_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 45e6df6c82..9fe472efe3 100644
--- a
>>> On 12.10.17 at 18:25, wrote:
> ... XENMEM_resource_ioreq_server
>
> This patch adds support for a new resource type that can be mapped using
> the XENMEM_acquire_resource memory op.
>
> If an emulator makes use of this resource type then, instead of mapping
> gfns, the IOREQ server will allo
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 October 2017 14:53
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-de...@lists.xenproject.org; Konrad Rzeszutek
> Wilk ; Tim (Xen.org)
> Subject:
On Mon, Oct 16, 2017 at 07:15:16AM -0600, Jan Beulich wrote:
On 13.10.17 at 07:10, wrote:
>> --- a/xen/arch/x86/hvm/irq.c
>> +++ b/xen/arch/x86/hvm/irq.c
>> @@ -168,11 +168,13 @@ void hvm_gsi_deassert(struct domain *d, unsigned int
>> gsi)
>> spin_unlock(&d->arch.hvm_domain.irq_lock);
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 October 2017 15:07
> To: Paul Durrant
> Cc: Andrew Cooper ; Ian Jackson
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v11
>>> On 16.10.17 at 16:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 October 2017 14:53
>> >>> On 12.10.17 at 18:25, wrote:
>> > --- a/xen/common/memory.c
>> > +++ b/xen/common/memory.c
>> > @@ -965,6 +965,88 @@ static long xatp_permission_check(struct domain
>> *d, unsign
flight 114539 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114539/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114224
test-amd64-amd64-xl-qemuu-ws16-amd64 10 w
>>> On 16.10.17 at 15:13, wrote:
> On Mon, Oct 16, 2017 at 07:15:16AM -0600, Jan Beulich wrote:
> On 13.10.17 at 07:10, wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -168,11 +168,13 @@ void hvm_gsi_deassert(struct domain *d, unsigned int
>>> gsi)
>>> sp
flight 114544 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114544/
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
Hi Volodymyr,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
Add basic OP-TEE mediator as an example how TEE mediator framework
works.
Currently it support only calls from Dom0. Calls from other guests
will be declined. It maps OP-TEE static shared memory region into
Dom0 address space, so Dom0 is
On Mon, Oct 16, 2017 at 08:26:09AM -0600, Jan Beulich wrote:
On 16.10.17 at 15:13, wrote:
>> On Mon, Oct 16, 2017 at 07:15:16AM -0600, Jan Beulich wrote:
>> On 13.10.17 at 07:10, wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -168,11 +168,13 @@ void hv
On Fri, 2017-10-13 at 16:38 +0100, Andrew Cooper wrote:
> On 13/10/17 13:35, Sergey Dyasli wrote:
> > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> > index a22e3dfaf2..2527fdd1d1 100644
> > --- a/xen/arch/x86/msr.c
> > +++ b/xen/arch/x86/msr.c
> > @@ -426,6 +426,13 @@ int init_vcpu_msr_pol
On 16/10/17 15:44, Wei Liu wrote:
> On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
>> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>>all state is actually set up. As it currently stands, d0v0 is eligible
>> for
>>scheduling before its registe
On Sun, Oct 15, 2017 at 03:31:15AM +0300, Michael S. Tsirkin wrote:
> On Fri, Oct 13, 2017 at 03:46:39PM -0700, Stefano Stabellini wrote:
> > On Fri, 13 Oct 2017, Jan Beulich wrote:
> > > >>> On 13.10.17 at 13:13, wrote:
> > > > To Jan, Andrew, Stefano and Anthony,
> > > >
> > > > what do you thi
>>> On 16.10.17 at 15:46, wrote:
> On Mon, Oct 16, 2017 at 08:26:09AM -0600, Jan Beulich wrote:
> On 16.10.17 at 15:13, wrote:
>>> On Mon, Oct 16, 2017 at 07:15:16AM -0600, Jan Beulich wrote:
>>> On 13.10.17 at 07:10, wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm
Hi Volodymyr,
On 11/10/17 20:01, Volodymyr Babchuk wrote:
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for bo
On Mon, Oct 16, 2017 at 02:51:54PM +0100, Andrew Cooper wrote:
> On 16/10/17 14:40, Wei Liu wrote:
> > On Fri, Oct 13, 2017 at 06:32:18PM +0100, Andrew Cooper wrote:
> >> c/s 4d69b3495 "Introduce migration precopy policy" uses bogus reasoning to
> >> justify passing precopy_stats by value.
> >>
> >
* x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
all state is actually set up. As it currently stands, d0v0 is eligible for
scheduling before its registers have been set. This is latent as we also
hold a systemcontroller pause reference at the time which preven
c/s cf6d39f8199 "x86/PV: properly populate descriptor tables" changed the GDT
to reference zero_page for intermediate frames between the guest and Xen
frames.
Because dom0_construct_pv() doesn't call arch_set_info_guest(), some bits of
initialisation are missed, including the pv_destroy_gdt() whic
On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>all state is actually set up. As it currently stands, d0v0 is eligible for
>scheduling before its registers have been set. This is latent as we als
On Mon, Oct 16, 2017 at 03:20:32PM +0200, Mohammed Gamal wrote:
> RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
> drivers use a minimum value of 0.
>
> When set MTU to 0~67 with xen_net{front|back} driver, the network
> will become unreachable immediately, the guest can no l
Wei Liu writes ("[PATCH for-4.10] libxl: annotate s to be nonnull in
libxl__enum_from_string"):
> Hope this can placate coverity.
Acked-by: Ian Jackson
We are very soon going to want "NN2" and maybe "NN_1_2".
Ian.
___
Xen-devel mailing list
Xen-deve
On Mon, Oct 16, 2017 at 03:49:54PM +0100, Andrew Cooper wrote:
> On 16/10/17 15:44, Wei Liu wrote:
> > On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
> >> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
> >>all state is actually set up. As it current
On Mon, Oct 16, 2017 at 03:20:32PM +0200, Mohammed Gamal wrote:
> RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
> drivers use a minimum value of 0.
>
> When set MTU to 0~67 with xen_net{front|back} driver, the network
> will become unreachable immediately, the guest can no l
On 10/16/2017 01:32 PM, Jan Beulich wrote:
> Since the emulator acts on the live hardware registers, we need to
> prevent the compiler from using them e.g. for inlined memcpy() /
> memset() (as gcc7 does).
Why doesn't this affect the rest of the hypervisor too, since we don't
save and restore the
~Andrew Cooper writes ("[PATCH for-4.10 2/2] tools/libxc: Fix various code
smells in send_memory_live()"):
> * Don't zero ctx->save.stats; it is already zeroed
> * No need for x as it duplicates ctx->save.stats.iteration
> * Defer setting dirty_count until the bitmap has been filled to match th
At least Linux kernels have been able to work with gzip-ed initrd for
quite some time; initrd compressed with other methods aren't even being
attempted to unpack. Furthermore the unzip-ing routine used here isn't
capable of dealing with various forms of concatenated files, each of
which was gzip-ed
Wei Liu writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to
not pass a structure by value"):
> On Mon, Oct 16, 2017 at 02:51:54PM +0100, Andrew Cooper wrote:
...
> > With Joshua's patch in place, the implementer of this callback is the
> > code generated by libxl_save_msgs_gen.p
Andrew Cooper writes ("Re: [Xen-devel] [xen-4.8-testing test] 114505:
regressions - FAIL"):
> On 15/10/17 20:45, osstest service owner wrote:
> > flight 114505 xen-4.8-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/114505/
> >
> > Regressions :-(
> >
> > Tests which did n
Hi all,
Xen 4.10 RC1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.10.0-rc1
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.10.0-rc1/xen-4.10.0-rc1.tar.gz
And the signature is at:
https://downloads.xenproject.or
>>> On 16.10.17 at 16:49, wrote:
> On 16/10/17 15:44, Wei Liu wrote:
>> On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
>>> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>>>all state is actually set up. As it currently stands, d0v0 is eligible
> f
>>> On 16.10.17 at 16:38, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -614,6 +614,7 @@ static int __init pvh_setup_cpus(struct domain *d,
> paddr_t entry,
>
> update_domain_wallclock_time(d);
>
> +v->is_initialised = 1;
> clear_bit(_V
>>> On 16.10.17 at 17:05, wrote:
> On 10/16/2017 01:32 PM, Jan Beulich wrote:
>> Since the emulator acts on the live hardware registers, we need to
>> prevent the compiler from using them e.g. for inlined memcpy() /
>> memset() (as gcc7 does).
>
> Why doesn't this affect the rest of the hypervis
On 16 October 2017 at 15:53, Jan Beulich wrote:
On 16.10.17 at 11:02, wrote:
>> static int console_create_ring(struct console *con)
>> {
>> - int err, remote_port, ring_ref, rc;
>> + int err, remote_port, rc;
>> + xen_pfn_t ring_ref;
>> char *type, path[PATH_MAX];
>>
On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>all state is actually set up. As it currently stands, d0v0 is eligible for
>scheduling before its registers have been set. This is latent as we als
>>> On 16.10.17 at 16:17, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 October 2017 15:07
>> >>> On 12.10.17 at 18:25, wrote:
>> > ... XENMEM_resource_ioreq_server
>> >
>> > This patch adds support for a new resource type that can be mapped using
>> > the XENMEM_acquire_reso
>>> On 16.10.17 at 17:47, wrote:
> On 16 October 2017 at 15:53, Jan Beulich wrote:
> On 16.10.17 at 11:02, wrote:
>>> static int console_create_ring(struct console *con)
>>> {
>>> - int err, remote_port, ring_ref, rc;
>>> + int err, remote_port, rc;
>>> + xen_pfn_t ring_ref;
>>
>>> On 16.10.17 at 16:38, wrote:
> c/s cf6d39f8199 "x86/PV: properly populate descriptor tables" changed the GDT
> to reference zero_page for intermediate frames between the guest and Xen
> frames.
>
> Because dom0_construct_pv() doesn't call arch_set_info_guest(), some bits of
> initialisation a
On Thu, Oct 12, 2017 at 12:10:25PM +0300, Alexandru Isaila wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the b
On Mon, Oct 02, 2017 at 05:13:47PM +0100, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Jan Beulich writes ("[PATCH] libxc: don't fail domain creation when unpacking
initrd fails"):
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine u
On 16/10/17 16:41, Jan Beulich wrote:
> >>> On 16.10.17 at 16:38, wrote:
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -614,6 +614,7 @@ static int __init pvh_setup_cpus(struct domain *d,
>> paddr_t entry,
>>
>> update_domain_wallclock_time(d);
>>
>>
>>> On 16.10.17 at 11:14, wrote:
> On 15/10/17 20:45, osstest service owner wrote:
>> flight 114505 xen-4.8-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/114505/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not
On 16/10/17 16:39, Jan Beulich wrote:
On 16.10.17 at 16:49, wrote:
>> On 16/10/17 15:44, Wei Liu wrote:
>>> On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
* x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
all state is actually set up. As
>>> On 16.10.17 at 17:45, wrote:
> Jan Beulich writes ("[PATCH] libxc: don't fail domain creation when unpacking
> initrd fails"):
>> At least Linux kernels have been able to work with gzip-ed initrd for
>> quite some time; initrd compressed with other methods aren't even being
>> attempted to un
>>> On 16.10.17 at 18:07, wrote:
> On 16/10/17 16:41, Jan Beulich wrote:
>> >>> On 16.10.17 at 16:38, wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -614,6 +614,7 @@ static int __init pvh_setup_cpus(struct domain *d,
>>> paddr_t entry,
>>>
>>>
On 16/10/17 16:51, Roger Pau Monné wrote:
> On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
>> * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
>>all state is actually set up. As it currently stands, d0v0 is eligible
>> for
>>scheduling before its
On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the b
On Mon, Oct 16, 2017 at 04:07:32PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy()
> to not pass a structure by value"):
> > On Mon, Oct 16, 2017 at 02:51:54PM +0100, Andrew Cooper wrote:
> ...
> > > With Joshua's patch in place, the implemen
On 16/10/17 17:12, Jan Beulich wrote:
On 16.10.17 at 11:14, wrote:
>> On 15/10/17 20:45, osstest service owner wrote:
>>> flight 114505 xen-4.8-testing real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/114505/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are
flight 114547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114547/
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 16/10/17 17:19, Jan Beulich wrote:
On 16.10.17 at 17:45, wrote:
>> Jan Beulich writes ("[PATCH] libxc: don't fail domain creation when
>> unpacking
>> initrd fails"):
>>> At least Linux kernels have been able to work with gzip-ed initrd for
>>> quite some time; initrd compressed with oth
On 16/10/17 16:16, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [xen-4.8-testing test] 114505:
> regressions - FAIL"):
>> On 15/10/17 20:45, osstest service owner wrote:
>>> flight 114505 xen-4.8-testing real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/114505/
>>>
>>
Jan Beulich writes ("Re: [PATCH] libxc: don't fail domain creation when
unpacking initrd fails"):
> On 16.10.17 at 17:45, wrote:
> > Is there no way to tell that a kernel supports gzipped initrds by
> > looking at the kernel ?
>
> Well, Linux kernels have config options controlling their ability
On 16/10/17 15:56, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.10] libxl: annotate s to be nonnull in
> libxl__enum_from_string"):
>> Hope this can placate coverity.
> Acked-by: Ian Jackson
>
> We are very soon going to want "NN2" and maybe "NN_1_2".
The hypervisor uses
#define __nonnull
Andrew Cooper writes ("Re: [Xen-devel] [PATCH] libxc: don't fail domain
creation when unpacking initrd fails"):
> IMO, the toolstack should not be making assumptions about the initrd,
> and shouldn't be touching it. It is the users responsibility to provide
> an initrd which its kernel can read.
On 16/10/17 16:58, Jan Beulich wrote:
On 16.10.17 at 16:38, wrote:
>> c/s cf6d39f8199 "x86/PV: properly populate descriptor tables" changed the GDT
>> to reference zero_page for intermediate frames between the guest and Xen
>> frames.
>>
>> Because dom0_construct_pv() doesn't call arch_set_in
Andrew Cooper writes ("Re: [Xen-devel] [PATCH for-4.10] libxl: annotate s to be
nonnull in libxl__enum_from_string"):
> On 16/10/17 15:56, Ian Jackson wrote:
> > We are very soon going to want "NN2" and maybe "NN_1_2".
>
> The hypervisor uses
>
> #define __nonnull(...) __attribute__((__nonnull__
1 - 100 of 118 matches
Mail list logo
