On 22.04.2020 18:31, Stefano Stabellini wrote:
> 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(cf
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
test-amd64-amd64-xl-qemuu-win7-amd6
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 tools/Rul
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):
tools:
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 b447a20bdfb2ff24ba048
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 the
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
test-amd64-i386-xl-qemuu-ws16-amd64
> 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, 3
> 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.
>
> Signed-
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 whic
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 @@ st
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 1
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 ad
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,
> > > */
> > > i
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 fla
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, &opaque_in, coun
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 tur
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 lastin
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 tag.
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 observe
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.
> > T
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
> > fuzzing
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 rea
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 1
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 succee
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 6e3c834ae47d1201c4ddc
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 sched_gran
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 fcd0
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 its
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 acpi_set_pdc_bits(u
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
> +++ b/docs/misc/p
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 recall
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. W
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 arch_vcpu_block(
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 a
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 << VMASST_TY
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,
> - {hap,shadow
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
exa
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() w
> 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 XEN_
52 matches
Mail list logo
