Re: [Xen-devel] Xen crash on S3 resume on 4.13 and unstable if any CPU is re-offlined

2020-01-04 Thread Marek Marczykowski-Górecki
On Sun, Jan 05, 2020 at 12:42:30AM +, Andrew Cooper wrote: > On 04/01/2020 15:30, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I have a reliable crash on resume from S3. I can reproduce it on both > > real hardware and nested within KVM, although call traces are different > > between

[Xen-devel] [qemu-mainline test] 145573: regressions - FAIL

2020-01-04 Thread osstest service owner
flight 145573 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145573/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861

Re: [Xen-devel] Xen crash on S3 resume on 4.13 and unstable if any CPU is re-offlined

2020-01-04 Thread Andrew Cooper
On 04/01/2020 15:30, Marek Marczykowski-Górecki wrote: > Hi, > > I have a reliable crash on resume from S3. I can reproduce it on both > real hardware and nested within KVM, although call traces are different > between those platforms. In any case, it happens only if some CPU is to > be

[Xen-devel] [libvirt bisection] complete build-i386-libvirt

2020-01-04 Thread osstest service owner
branch xen-unstable xenbranch xen-unstable job build-i386-libvirt testid libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/ Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: ovmf

[Xen-devel] [PATCH v5 3/3] golang/xenlight: implement array Go to C marshaling

2020-01-04 Thread Nick Rosbrook
Signed-off-by: Nick Rosbrook --- Changes in v5: - Remove dispose_fn from parameter list in xenlight_golang_array_to_C since it's no longer needed. - Update call to toC for elements of arrays of structs so that it matches the new function signature of toC. - Do not try to marshal zero-length

[Xen-devel] [PATCH v5 1/3] golang/xenlight: begin Go to C type marshaling

2020-01-04 Thread Nick Rosbrook
Implement conversions for basic types such as strings and integer types in toC functions. Modify function signatures of toC implementations for builtin types to be consistent with the signature of the generated toC functions. Signed-off-by: Nick Rosbrook --- Changes in v5: - Define

[Xen-devel] [PATCH v5 0/3] generated Go libxl bindings using IDL

2020-01-04 Thread Nick Rosbrook
After Xen summit, we started the discussion in this[1] RFC thread to figure out how to generate Go bindings for libxl. This series implements that Go code generation using the existing IDL, and updates the existing hand-written code in xenlight.go to use the generated code. The goal of this

[Xen-devel] [PATCH v5 2/3] golang/xenlight: implement keyed union Go to C marshaling

2020-01-04 Thread Nick Rosbrook
Since the C union cannot be directly populated, populate the fields of the corresponding C struct defined in the cgo preamble, and then copy that struct as bytes into the byte slice that Go uses as the union. Signed-off-by: Nick Rosbrook --- Changes in v5: - Make use of

[Xen-devel] [qemu-mainline test] 145547: regressions - FAIL

2020-01-04 Thread osstest service owner
flight 145547 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145547/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861

Re: [Xen-devel] [PATCH 6/9] golang/xenlight: Errors are negative

2020-01-04 Thread Nick Rosbrook
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote: > > Commit 871e51d2d4 changed the sign on the xenlight error types (making > the values negative, same as the C-generated constants), but failed to > flip the sign in the Error() string function. The result is that > ErrorNonspecific.String()

Re: [Xen-devel] [PATCH 5/9] go/xenlight: More informative error messages

2020-01-04 Thread Nick Rosbrook
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote: > > If an error is encountered deep in a complicated data structure, it's > often difficult to tell where the error actually is. Make the error > message from the generated toC() and fromC() structures more > informative by tagging which

Re: [Xen-devel] [PATCH 4/9] go/xenlight: Fix CpuidPoliclyList conversion

2020-01-04 Thread Nick Rosbrook
> Empty Go strings should be converted to `nil` libxl_cpuid_policy_list; > otherwise libxl_cpuid_parse_config gets confused. > > Also, libxl_cpuid_policy_list returns a weird error, not a "normal" > libxl error; if it returns one of these non-standard errors, convert > it to ErrorInval. > >

Re: [Xen-devel] [PATCH 3/9] golang/xenlight: Convert "" to NULL

2020-01-04 Thread Nick Rosbrook
> C.GoString will handle NULL C strings properly, by passing back "". > But C.CString will take an empty Go string and actually generate a > '\0'-terminated empty string. This confuses libxl, which is expecting > non-values to be NULL, not "". > > Only call C.CString if the Go string is

Re: [Xen-devel] [PATCH 2/9] golang/xenlight: Do proper nil / NULL conversions for builtin Bitmap type

2020-01-04 Thread Nick Rosbrook
On Fri, Dec 27, 2019 at 11:33 AM George Dunlap wrote: > > Similar to the autogenerated types, but for `builtin` Bitmap type. > > Signed-off-by: George Dunlap Reviewed-by: Nick Rosbrook ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH 1/9] golang/xenlight: Don't try to marshall zero-length arrays

2020-01-04 Thread Nick Rosbrook
> The current fromC array code will do the "magic" casting and > martialling even when num_foo variable is 0. Go crashes when doing > the cast. > > Furthermore, the current toC array code will convert a nil slice into > a zero-length malloc. The resulting pointer is non-NULL, and confuses >

[Xen-devel] Xen crash on S3 resume on 4.13 and unstable if any CPU is re-offlined

2020-01-04 Thread Marek Marczykowski-Górecki
Hi, I have a reliable crash on resume from S3. I can reproduce it on both real hardware and nested within KVM, although call traces are different between those platforms. In any case, it happens only if some CPU is to be re-offlined after resume (smt=off and/or maxcpus=... options). I think the

[Xen-devel] [xen-unstable test] 145538: tolerable FAIL - PUSHED

2020-01-04 Thread osstest service owner
flight 145538 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/145538/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 145025

[Xen-devel] [qemu-mainline test] 145535: regressions - FAIL

2020-01-04 Thread osstest service owner
flight 145535 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/145535/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861