flight 149737 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149737/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 149723
flight 149731 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149731/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149711
test-amd64-amd64-xl-qemut-win7-amd64
By default, if the go compiler is found by the configure script, build
the golang tools. If the compiler is not found, and
--enable-golang_tools was not explicitly set, do not build to the golang
tools.
The new corresponding make variable is CONFIG_GOLANG_TOOLS. Remove
CONFIG_GOLANG from
These patches add support for the golang tools in the build system.
The behavior of configure with respect to the new variable,
CONFIG_GOLANG_TOOLS is copied from other components, such as the Ocaml
tools. Namely, build the tools by default if the go compiler is found.
Nick Rosbrook (2):
flight 149735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149735/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c6a60cf4b99069f55325675c7c7e98b510f4b224
baseline version:
ovmf
flight 149732 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
> I feel like I want to say here what it is you actually have to fill in to
> remove the nic; but after 10 minutes of poking around the code, I’m not
> actually sure myself. :-) (I think it *might* be just Devid and
> BackendDomid.)
IIRC, you can use just the MAC or devid. I was using just
flight 149728 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149728/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds15 guest-saverestore fail in 149709 pass in 149728
> libxl.h defines INVALID_DOMID — do we want to define an exported constant
> with the same name and use that here? (Although part of me wonders if
> DOMID_INVALID would be a better option.)
Yeah, that makes sense. I'll add that.
> > + }
> > +
> > + return Domid(domid), nil
> > +}
> >
> One question I have from the above is how the xen.git RELEASE-X.Y.Z should
> correspond to the vA.B.C in the golang package repo.
>
> The obvious answer, of course, is (A, B, C) = (X, Y, Z); that is, xen.git tag
> RELEASE-4.14.0 should create a golang package tag of v4.14.0.
>
> The issue with
> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
>
> Add DeviceNicAdd and DeviceNicRemove as wrappers for
> libxl_device_nic_add and libxl_device_nic_remove.
>
> Signed-off-by: Nick Rosbrook
> ---
> tools/golang/xenlight/xenlight.go | 34 +++
> 1 file changed,
> On Apr 12, 2020, at 11:02 PM, Nick Rosbrook wrote:
>
> Many exported functions in xenlight require a domid as an argument. Make
> it easier for package users to use these functions by adding wrappers
> for the libxl utility functions libxl_name_to_domid and
> libxl_domid_to_name.
>
>
flight 149726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
149705
Tests
On Wed, Apr 22, 2020 at 9:50 AM Roger Pau Monné wrote:
>
> On Wed, Apr 22, 2020 at 06:42:42AM -0600, Tamas K Lengyel wrote:
> > On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monné
> > wrote:
> > >
> > > On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > > > @@ -666,20 +670,31 @@
On Thu, Apr 16, 2020 at 03:59:07PM +0200, Roger Pau Monne wrote:
> @@ -254,3 +257,14 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
>
> return flags;
> }
> +
> +void guest_flush_tlb_mask(const struct domain *d, const cpumask_t *mask)
> +{
> +unsigned int flags
On Wed, 22 Apr 2020, Jan Beulich wrote:
> On 22.04.2020 15:07, Juergen Gross wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -3626,12 +3626,12 @@ do_grant_table_op(
> > if ( unlikely(!guest_handle_okay(cflush, count)) )
> > goto out;
> >
flight 149736 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149736/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
So currently, our build system will install the xenlight package into
$PREFIX/share/gocode/src/golang.xenproject.org/xenlight. However, it actually
takes a bit of wrestling to get golang to use this location, and makes it
difficult to use shared code. It would be nice if people could simply
On Wed, Apr 22, 2020 at 06:42:42AM -0600, Tamas K Lengyel wrote:
> On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monné wrote:
> >
> > On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > > @@ -666,20 +670,31 @@ static int page_make_sharable(struct domain *d,
> > > */
> > >
Le lun. 20 avr. 2020 à 22:56, Andrew Cooper
a écrit :
> Really? The status handling is certainly different, but v2 is much
> harder to use correctly.
In which sense?
>From granter standpoint it seems to be just checking the status on
different place. Of course you can't atomically check the
On 22.04.2020 15:07, Juergen Gross wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3626,12 +3626,12 @@ do_grant_table_op(
> if ( unlikely(!guest_handle_okay(cflush, count)) )
> goto out;
> rc = gnttab_cache_flush(cflush, _in, count);
>
On 22.04.20 15:43, Julien Grall wrote:
Hi Juergen,
On 22/04/2020 14:07, Juergen Gross wrote:
The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
continuation, the test today is:
if ( rc > 0 || opaque_out != 0 )
Unfortunately this will be true even in case of an error (rc <
On 22/04/2020 14:43, Julien Grall wrote:
Hi Juergen,
On 22/04/2020 14:07, Juergen Gross wrote:
The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
continuation, the test today is:
if ( rc > 0 || opaque_out != 0 )
Unfortunately this will be true even in case of an error
Roger Pau Monne writes ("Re: [PATCH] Introduce a description of the Backport
and Fixes tags"):
> On Tue, Apr 21, 2020 at 07:49:15PM +0100, Ian Jackson wrote:
> > Acked-by: Ian Jackson
> >
> > > +When possible, please use the Fixes tag instead (or in addition).
> >
> > Do we have any code to
Hi Juergen,
On 22/04/2020 14:07, Juergen Gross wrote:
The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
continuation, the test today is:
if ( rc > 0 || opaque_out != 0 )
Unfortunately this will be true even in case of an error (rc < 0),
possibly leading to very long
On Tue, Apr 21, 2020 at 07:49:15PM +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH] Introduce a description of the Backport
> and Fixes tags"):
> > Create a new document under docs/process to describe our special tags.
> > Add a description of the Fixes tag and the new Backport
The conversion of xen_pt_initfn() to xen_pt_realize() blindly replaced
XEN_PT_ERR() by error_setg(). Several error conditions that did not
fail xen_pt_initfn() now fail xen_pt_realize(). Unsurprisingly, the
cleanup on these errors looks highly suspicious.
Revert the inappropriate replacements.
The GNTTABOP_cache_flush hypercall has a wrong test for hypercall
continuation, the test today is:
if ( rc > 0 || opaque_out != 0 )
Unfortunately this will be true even in case of an error (rc < 0),
possibly leading to very long lasting hypercalls (times of more
than an hour have been
On Wed, Apr 22, 2020 at 3:00 AM Roger Pau Monné wrote:
>
> On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> > When resetting a VM fork we ought to only remove pages that were allocated
> > for
> > the fork during it's execution and the contents copied over from the parent.
> >
On Wed, Apr 22, 2020 at 3:09 AM Roger Pau Monné wrote:
>
> On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote:
> > The memory sharing subsystem by default doesn't allow a domain to share
> > memory
> > if it has an IOMMU active for obvious security reasons. However, when
> >
On 20/04/2020 06:48, Jan Beulich wrote:
> On 17.04.2020 21:46, Andrew Cooper wrote:
>> On 17/04/2020 15:25, Jan Beulich wrote:
>>> Drop the NULL checks - they've been introduced by commit 8d7b633ada
>>> ("x86/mm: Consolidate all Xen L4 slot writing into
>>> init_xen_l4_slots()") for no apparent
flight 149733 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149733/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 149723 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149723/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 149681
Tests which did not
flight 149725 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149725/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b447a20bdfb2ff24ba048bb3026c902c4768a7e9
baseline version:
ovmf
On 22.04.2020 11:30, Sergey Dyasli wrote:
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -40,19 +40,50 @@ static DEFINE_SPINLOCK(cpupool_lock);
> static enum sched_gran __read_mostly opt_sched_granularity = SCHED_GRAN_cpu;
> static unsigned int __read_mostly
flight 149734 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149734/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5730ac3c8346f56fe8ee90249cdcbdab2a4d5791
baseline version:
xen
On 22.04.2020 10:17, Julien Grall wrote:
> On 21/04/2020 10:13, Jan Beulich wrote:
>> First of all avoid excessive conversions. copy_{from,to}_guest(), for
>> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
>>
>> Further
>> - do_physdev_op_compat() didn't use the param form for its
Currently it might be not obvious which scheduling mode (e.g. core-
scheduling) is being used by the scheduler. Alleviate this by printing
additional information about the selected granularity per-cpupool.
Note: per-cpupool granularity selection is not implemented yet. Every
cpupool gets
On 22.04.2020 10:26, Roger Pau Monné wrote:
> On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/acpi/pmstat.c
>> +++ b/xen/drivers/acpi/pmstat.c
>> @@ -492,7 +492,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op
>> return ret;
>> }
>>
>> -int
On 22.04.2020 01:27, Stefano Stabellini wrote:
> On Mon, 20 Apr 2020, Jan Beulich wrote:
>> On 20.04.2020 15:34, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 20/04/2020 09:04, Jan Beulich wrote:
On 19.04.2020 12:49, Julien Grall wrote:
> --- a/docs/misc/pvcalls.pandoc
> +++
On 21.04.2020 20:22, Stefano Stabellini wrote:
> On Mon, 20 Apr 2020, Jan Beulich wrote:
>> On 18.04.2020 00:24, Stefano Stabellini wrote:
>> Previously I did suggest to add an indication that people requesting
>> backports should also be prepare to actually help with backporting.
>> I don't
On Tue, Apr 21, 2020 at 10:47:24AM -0700, Tamas K Lengyel wrote:
> The memory sharing subsystem by default doesn't allow a domain to share memory
> if it has an IOMMU active for obvious security reasons. However, when fuzzing
> a
> VM fork, the same security restrictions don't necessarily apply.
On 22/04/2020 10:04, Jan Beulich wrote:
On 22.04.2020 10:57, Julien Grall wrote:
On 21/04/2020 15:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
static inline void
On 22.04.2020 10:57, Julien Grall wrote:
> On 21/04/2020 15:39, Jan Beulich wrote:
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
>> static inline void arch_vcpu_block(struct vcpu *v) {}
>> +#define
On Tue, Apr 21, 2020 at 10:47:23AM -0700, Tamas K Lengyel wrote:
> When resetting a VM fork we ought to only remove pages that were allocated for
> the fork during it's execution and the contents copied over from the parent.
> This can be determined if the page is sharable as special pages used by
Hi Jan,
On 21/04/2020 15:39, Jan Beulich wrote:
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -269,6 +269,8 @@ static inline void free_vcpu_guest_conte
static inline void arch_vcpu_block(struct vcpu *v) {}
+#define arch_vm_assist_valid_mask(d) (1UL <<
On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
> First of all avoid excessive conversions. copy_{from,to}_guest(), for
> example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
>
> Further
> - do_physdev_op_compat() didn't use the param form for its parameter,
> -
Hi,
On 22/04/2020 08:56, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 07:44:55PM +0100, Julien Grall wrote:
Hi,
On 21/04/2020 18:30, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
Hi Jan,
On 21/04/2020 10:13, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().
Further
- do_physdev_op_compat() didn't use the param form for its parameter,
- {hap,shadow}_track_dirty_vram()
> From: Andrew Cooper
> Sent: Monday, April 20, 2020 10:59 PM
>
> This will cause all SYSCALL/SYSRET instructions to suffer #UD rather than
> following the MSR_{L,C}STAR pointers, allowing us to drop the star_enter()
> panic helper, allowing us to clean up the IST stacks in a subsequent patch.
>
On Tue, Apr 21, 2020 at 07:44:55PM +0100, Julien Grall wrote:
> Hi,
>
> On 21/04/2020 18:30, Roger Pau Monné wrote:
> > On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
> > > First of all avoid excessive conversions. copy_{from,to}_guest(), for
> > > example, work fine with all of
At 11:11 +0200 on 21 Apr (1587467497), Jan Beulich wrote:
> Consolidate the shadow_mode_external() in here: Check this once at the
> start of the function.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
> Acked-by: Tim Deegan
> ---
> v2: Delete stale part of comment.
> ---
> Tim -
At 14:05 +0200 on 21 Apr (1587477956), Jan Beulich wrote:
> Despite the inline attribute at least some clang versions warn about
> trace_shadow_wrmap_bf() being unused in !HVM builds. Include the helper
> in the #ifdef region.
>
> Fixes: 8b8d011ad868 ("x86/shadow: the guess_wrmap() hook is needed
53 matches
Mail list logo
