[Xen-devel] [libvirt test] 114531: tolerable all pass - PUSHED

flight 114531 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/114531/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114503 test-armhf-armhf-libvirt 14

[Xen-devel] [linux-linus test] 114528: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v3 5/6] x86/msr: update domain policy on CPUID policy changes

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

Re: [Xen-devel] [PATCH v3 2/6] x86/msr: add VMX MSRs into struct msr_domain_policy

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; > > + > > +/*

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

flight 114525 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/114525/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 8 xen-buildfail REGR. vs. 114204

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 not succeed and are blocking, > including tests which could not be run: > test-xtf-amd64-amd64-2 48

Re: [Xen-devel] libxl: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

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:

[Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

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"

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

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,

[Xen-devel] [PATCH] toolcore: Build in rumprun environment too

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

Re: [Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

>>> 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 =

Re: [Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

>>> 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

Re: [Xen-devel] [PATCH v1 1/2] tools/libs/evtchn: Add support for restricting a handle

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.

Re: [Xen-devel] [PATCH v2 2/2] xentoolcore_restrict_all: Implement for libxenevtchn

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 >

Re: [Xen-devel] [PATCH v1 1/2] tools/libs/evtchn: Add support for restricting a handle

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

[Xen-devel] [PATCH] toolcore: Build in rumprun environment too

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

Re: [Xen-devel] [PATCH v1 1/2] tools/libs/evtchn: Add support for restricting a handle

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 >

[Xen-devel] [xen-4.9-testing test] 114533: regressions - FAIL

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

Re: [Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err

>>> 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

Re: [Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

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

Re: [Xen-devel] [PATCH] toolcore: Build in rumprun environment too

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

[Xen-devel] [xen-4.6-testing baseline-only test] 72239: regressions - FAIL

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

Re: [Xen-devel] [PATCH] toolcore: Build in rumprun environment too

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

Re: [Xen-devel] [PATCH] toolcore: Build in rumprun environment too

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

Re: [Xen-devel] [PATCH v2] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

>>> 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(>arch.hvm_domain.irq_lock); > } > > -void hvm_isa_irq_assert( > -struct

[Xen-devel] [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values

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

[Xen-devel] [xen-4.8-testing test] 114538: tolerable FAIL - PUSHED

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

[Xen-devel] [distros-debian-sid test] 72240: tolerable trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

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

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

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

Re: [Xen-devel] [PATCH v1 1/2] tools/libs/evtchn: Add support for restricting a handle

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

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

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

[Xen-devel] [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

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

Re: [Xen-devel] [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

>>> 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

Re: [Xen-devel] [PATCH v6] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

>>> 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,

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

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).

Re: [Xen-devel] [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

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

Re: [Xen-devel] [PATCH v8 08/16] x86: implement set value flow for MBA

>>> 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

Re: [Xen-devel] [RFC 2/4] arm: add generic TEE mediator framework

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

[Xen-devel] [PATCH for-next] xen/pv: Construct d0v0's GDT properly

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()

Re: [Xen-devel] [PATCH for-next] xen/pv: Construct d0v0's GDT properly

>>> 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(),

Re: [Xen-devel] [PATCH for-next 1/3] x86/smp: Rework cpu_smpboot_alloc() to cope with more than just -ENOMEM

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

Re: [Xen-devel] [PATCH v1] x86/hvm: Add MSR old value

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

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

>>> 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

Re: [Xen-devel] [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values

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

Re: [Xen-devel] [PATCH for-4.10 2/2] tools/libxc: Fix various code smells in send_memory_live()

~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

Re: [Xen-devel] [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

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

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

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/ >>>

Re: [Xen-devel] [PATCH v2] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

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) >>

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

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

[Xen-devel] Xen 4.10 RC1

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:

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

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

Re: [Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

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

[Xen-devel] [seabios test] 114539: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v2] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

>>> 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

Re: [Xen-devel] [PATCH v3 6/6] x86/msr: handle VMX MSRs with guest_rd/wrmsr()

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

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

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

Re: [Xen-devel] [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: > 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. > >> >

[Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

* 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

Re: [Xen-devel] [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values

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

[Xen-devel] [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 used here isn't capable of dealing with various forms of concatenated files, each of which was

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

>>> 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

Re: [Xen-devel] [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

>>> 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

[Xen-devel] [xen-unstable-smoke test] 114547: tolerable all pass - PUSHED

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

Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator

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

Re: [Xen-devel] [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

Re: [Xen-devel] [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> 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

[Xen-devel] [xen-unstable-smoke test] 114544: tolerable all pass - PUSHED

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

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

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, > > >

Re: [Xen-devel] [PATCH v2] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

>>> 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:

Re: [Xen-devel] [PATCH for-4.10] libxl: annotate s to be nonnull in libxl__enum_from_string

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. ___

Re: [Xen-devel] [PATCH v11 06/11] x86/hvm/ioreq: add a new mappable resource type...

>>> 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

Re: [Xen-devel] libxl/xenconsole: vpl011: Fix hex to dec conversion of vuart_gfn in libxl__device_vuart_add

>>> 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,

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

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

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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, >> >>

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

>>> 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

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

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

Re: [Xen-devel] [PATCH for-4.10] libxl: annotate s to be nonnull in libxl__enum_from_string

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(...)

Re: [Xen-devel] [PATCH for-next] xen/pv: Construct d0v0's GDT properly

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

[Xen-devel] [PATCH v7] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

From: Razvan Cojocaru For the default EPT view we have xc_set_mem_access_multi(), which is able to set an array of pages to an array of access rights with a single hypercall. However, this functionality was lacking for the altp2m subsystem, which could only set page

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

On Mon, 16 Oct 2017, 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 also >hold a

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

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

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

On 10/12/2017 03:53 PM, Boris Ostrovsky wrote: > On 10/12/2017 03:27 PM, Andrew Cooper wrote: >> On 12/10/17 20:11, Boris Ostrovsky wrote: >>> There is also another problem: >>> >>> [1.312425] general protection fault: [#1] SMP >>> [1.312901] Modules linked in: >>> [1.313389] CPU:

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: > 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

Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

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.

Re: [Xen-devel] [PATCH v11 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -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- >

Re: [Xen-devel] [PATCH v2] x86/vpt: guarantee the return value of pt_update_irq() set in vIRR or PIR

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 +++

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

>>> 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); > > +

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

>>> 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, >>

Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

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

Re: [Xen-devel] [PATCH v2] x86/hvm: Add MSR old value

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

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

flight 114540 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/114540/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 8 xen-buildfail REGR. vs. 114204

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

flight 114543 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/114543/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 14 guest-localmigrate fail in 114533 pass in 114543

Re: [Xen-devel] [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values

On 10/16/2017 11:05 AM, Wei Liu wrote: > 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

  1   2   >