> From: Alexandru Isaila
> Sent: Monday, March 30, 2020 2:55 PM
>
> At this moment a guest can call vmfunc to change the altp2m view. This
> should be limited in order to avoid any unwanted view switch.
>
> The new xc_altp2m_set_visibility() solves this by making views invisible
> to vmfunc.
>
flight 149556 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149556/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On Thu, Apr 9, 2020 at 6:58 PM Andrew Cooper wrote:
>
> On 10/04/2020 00:23, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper
> > wrote:
> >> On 09/04/2020 23:38, Tamas K Lengyel wrote:
> >>> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper
> >>> wrote:
> On 09/04/2020
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On 10/04/2020 00:23, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper
> wrote:
>> On 09/04/2020 23:38, Tamas K Lengyel wrote:
>>> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper
>>> wrote:
On 09/04/2020 22:24, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 2:48 PM
On Thu, Apr 9, 2020 at 5:00 PM Andrew Cooper wrote:
>
> On 09/04/2020 23:38, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper
> > wrote:
> >> On 09/04/2020 22:24, Tamas K Lengyel wrote:
> >>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper
> >>> wrote:
> A default
On 09/04/2020 23:38, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper
> wrote:
>> On 09/04/2020 22:24, Tamas K Lengyel wrote:
>>> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper
>>> wrote:
A default build fails with:
mem_sharing.c: In function
On Thu, Apr 9, 2020 at 4:05 PM Andrew Cooper wrote:
>
> On 09/04/2020 22:24, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper
> > wrote:
> >> A default build fails with:
> >>
> >> mem_sharing.c: In function ‘copy_special_pages’:
> >> mem_sharing.c:1649:9: error:
On 09/04/2020 22:24, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper
> wrote:
>> A default build fails with:
>>
>> mem_sharing.c: In function ‘copy_special_pages’:
>> mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use
>> in this function)
>>
On Thu, Apr 9, 2020 at 2:48 PM Andrew Cooper wrote:
>
> A default build fails with:
>
> mem_sharing.c: In function ‘copy_special_pages’:
> mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in
> this function)
>HVM_PARAM_STORE_PFN,
>
A default build fails with:
mem_sharing.c: In function ‘copy_special_pages’:
mem_sharing.c:1649:9: error: ‘HVM_PARAM_STORE_PFN’ undeclared (first use in
this function)
HVM_PARAM_STORE_PFN,
^~~
I suspect this is a rebasing issue with respect to c/s
flight 149554 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 148185
Tests which
On Thu, Apr 09, 2020 at 09:41:49AM +0200, Jan Beulich wrote:
> All,
>
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all
flight 149568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149568/
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
Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
of several hypercalls:
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
* HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
* HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
Pick the most efficient hypercalls available.
Implement a basic hook for L0 assisted TLB flush. The hook needs to
check if prerequisites are met. If they are not met, it returns an error
number to fall back to native flushes.
Introduce a new variable to indicate if hypercall page is ready.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau
Hi all
This seris is based on Roger's L0 assisted flush series v9. In patch 1 I
dropped FLUSH_TLB_FLAGS_MASK per Jan's request. Other than that, nothing
is changed.
Wei.
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monné
Cc: Michael Kelley
Cc: Paul Durrant
Wei Liu (3):
Hyper-V's L0 assisted flush has fine-grained control over what gets
flushed. We need all the flags available to make the best decisions
possible.
No functional change because Xen's implementation doesn't care about
what is passed to it.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
>
> On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> [...]
> > >
> > > >
> > > > > >
> > > > > > +/*
> > > > > > + * The parent domain is expected to be created with default
> > > > > > settings for
> > > > > > + * - max_evtch_port
On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
[...]
> >
> > >
> > > > >
> > > > > +/*
> > > > > + * The parent domain is expected to be created with default settings
> > > > > for
> > > > > + * - max_evtch_port
> > > > > + * - max_grant_frames
> > > > > + * -
On Thu, Apr 9, 2020 at 10:22 AM Wei Liu wrote:
>
> On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
> > >
> > > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > > Add necessary bits to implement "xl fork-vm"
flight 149553 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149553/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 148126
test-armhf-armhf-xl-rtds 16
On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
> >
> > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > Add necessary bits to implement "xl fork-vm" commands. The command allows
> > > the
> > > user to
On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
>
> On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > Add necessary bits to implement "xl fork-vm" commands. The command allows
> > the
> > user to specify how to launch the device model allowing for a late-launch
> > model
> > in
On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch
> model
> in which the user can execute the fork without the device model
On Wed, Apr 08, 2020 at 10:00:48AM +0200, Jan Beulich wrote:
> Commit e3a379c35eff ("x86/time: always count s_time from Xen boot")
> introducing this missed adjusting this path as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
On Tue, Apr 07, 2020 at 05:10:59PM +0100, Ian Jackson wrote:
> Dmitry Isaykin writes ("[PATCH] tools/xl: Remove the filelock when building
> VM if autoballooning is off"):
> > The presence of this filelock does not allow building several VMs at the
> > same
> > time. This filelock was added to
On 09.04.20 16:44, Boris Ostrovsky wrote:
On 4/9/20 3:00 AM, Juergen Gross wrote:
Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
introduced a regression for booting 32 bit Xen PV guests: the address
of the initial stack needs to be a virtual one.
Fixes: 2f62f36e62daec
On Thu, Apr 09, 2020 at 04:35:27PM +0200, Samuel Thibault wrote:
> Juergen Gross, le jeu. 09 avril 2020 16:12:40 +0200, a ecrit:
> > There are several instances of calls to xenbus functions which don't
> > test for an error and in consequence are not freeing the returned
> > error strings, or
On 4/9/20 3:00 AM, Juergen Gross wrote:
> Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
> introduced a regression for booting 32 bit Xen PV guests: the address
> of the initial stack needs to be a virtual one.
>
> Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle
Panyakin, Andrew writes ("Re: [XEN PATCH] libxc/migration: Abort migration on
precopy policy request"):
> On 4/7/20 10:22 PM, Wei Liu wrote:
> > There is no need to have "goto out" here.
>
> I was considering two more examples of "goto out" in a branch right before
> the label:
> -
Juergen Gross, le jeu. 09 avril 2020 16:12:40 +0200, a ecrit:
> There are several instances of calls to xenbus functions which don't
> test for an error and in consequence are not freeing the returned
> error strings, or which are just not freeing the string after e.g.
> printing it.
>
> Fix that
Juergen Gross, le jeu. 09 avril 2020 16:12:39 +0200, a ecrit:
> Commit 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore
> support for xenbus") introduced a double free of some memory and leaked
> another memory allocation.
>
> Fix those.
>
> Coverity-ID: 1433640
> Fixes: 973ad0c4de1b48
Juergen Gross, le jeu. 09 avril 2020 16:12:38 +0200, a ecrit:
> Commit d225f4012d69a19 ("Save/Restore Support: Add suspend/restore
> support for netfront") introduced a regression in form of freeing a
> netfront device structure twice.
>
> Fix that.
>
> Coverity-ID: 1433637
> Fixes:
On Wed, Apr 08, 2020 at 12:06:22AM +0200, Panyakin, Andrew wrote:
> On 4/7/20 10:22 PM, Wei Liu wrote:
> > On Tue, Apr 07, 2020 at 02:52:22PM +, Andrew Panyakin wrote:
> >> libxc defines XGS_POLICY_ABORT for precopy policy to signal that migration
> >> should be aborted (eg. if the estimated
On Thu, Apr 09, 2020 at 04:12:37PM +0200, Juergen Gross wrote:
> This series fixes two double free() introduced by suspend/resume
> patches and several memory leaks.
>
> Juergen Gross (3):
> mini-os: fix double free() in netfront
> mini-os: fix double free() in xenbus
> mini-os: fix several
Hi Christoph
On Thu, Apr 09, 2020 at 08:37:48AM +0200, Jürgen Groß wrote:
> Adjusting recipient list (dropping David, new mail addresses for Wei and
> Paul).
>
> On 09.04.20 08:18, Christoph Hellwig wrote:
> > Hi Wei,
> >
> > commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
> >
Commit d225f4012d69a19 ("Save/Restore Support: Add suspend/restore
support for netfront") introduced a regression in form of freeing a
netfront device structure twice.
Fix that.
Coverity-ID: 1433637
Fixes: d225f4012d69a19 ("Save/Restore Support: Add suspend/restore support for
netfront")
This series fixes two double free() introduced by suspend/resume
patches and several memory leaks.
Juergen Gross (3):
mini-os: fix double free() in netfront
mini-os: fix double free() in xenbus
mini-os: fix several memory leaks related to xenbus
blkfront.c | 4 ++--
Commit 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore
support for xenbus") introduced a double free of some memory and leaked
another memory allocation.
Fix those.
Coverity-ID: 1433640
Fixes: 973ad0c4de1b48 ("Save/Restore Support: Add suspend/restore support for
xenbus")
There are several instances of calls to xenbus functions which don't
test for an error and in consequence are not freeing the returned
error strings, or which are just not freeing the string after e.g.
printing it.
Fix that by either adding the needed calls of free().
Coverity-ID: 1433632
flight 149547 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149547/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 149478
On 09/04/2020 13:56, Julien Grall wrote:
On 09/04/2020 02:26, Stefano Stabellini wrote:
On Tue, 7 Apr 2020, Julien Grall wrote:
I don’t know what maintenance IRQs are, but if they only happen
intermittently, it’s possible that you’d never get more than a single
one in a latency-critical
On 09/04/2020 02:26, Stefano Stabellini wrote:
On Tue, 7 Apr 2020, Julien Grall wrote:
I don’t know what maintenance IRQs are, but if they only happen
intermittently, it’s possible that you’d never get more than a single
one in a latency-critical IRQ routine; and as such, the variatibility
On 09.04.20 11:41, Sergey Dyasli wrote:
In core-scheduling mode, Xen might crash when entering ACPI S5 state.
This happens in sched_slave() during is_idle_unit(next) check because
next->vcpu_list is stale and points to an already freed memory.
This situation happens shortly after
On 09.04.20 12:35, Jan Beulich wrote:
On 09.04.2020 12:23, Jürgen Groß wrote:
On 09.04.20 11:00, Jan Beulich wrote:
On 09.04.2020 10:56, Jürgen Groß wrote:
On 09.04.20 10:00, Jan Beulich wrote:
On 09.04.2020 09:31, Jürgen Groß wrote:
On 09.04.20 04:30, osstest service owner wrote:
flight
On 25.03.2020 22:12, Andrew Cooper wrote:
> On 24/03/2020 12:33, Jan Beulich wrote:
>> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
>> generated header instead of (at least once per [sub]directory) into
>> CFLAGS. This results in proper rebuilds (via make dependencies) in
On 06.04.2020 12:57, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> p2m_change_type_range(d, begin_pfn, begin_pfn + nr,
>p2m_ram_rw,
From: Colin Ian King
The variable irq is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
arch/x86/pci/xen.c | 2 +-
1
On 08.04.2020 17:10, Roger Pau Monné wrote:
> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/paging.c
>>> +++ b/xen/arch/x86/mm/paging.c
>>> @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d,
>>>
On 09.04.2020 12:23, Jürgen Groß wrote:
> On 09.04.20 11:00, Jan Beulich wrote:
>> On 09.04.2020 10:56, Jürgen Groß wrote:
>>> On 09.04.20 10:00, Jan Beulich wrote:
On 09.04.2020 09:31, Jürgen Groß wrote:
> On 09.04.20 04:30, osstest service owner wrote:
>> flight 149520 xen-unstable
On 09.04.20 11:00, Jan Beulich wrote:
On 09.04.2020 10:56, Jürgen Groß wrote:
On 09.04.20 10:00, Jan Beulich wrote:
On 09.04.2020 09:31, Jürgen Groß wrote:
On 09.04.20 04:30, osstest service owner wrote:
flight 149520 xen-unstable real [real]
flight 149527 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 149238
In core-scheduling mode, Xen might crash when entering ACPI S5 state.
This happens in sched_slave() during is_idle_unit(next) check because
next->vcpu_list is stale and points to an already freed memory.
This situation happens shortly after scheduler_disable() is called if
some CPU is still
On 08.04.2020 15:36, Hongyan Xia wrote:
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -168,16 +168,17 @@ const struct platform_bad_page *__init
> pv_shim_reserved_pages(unsigned int *size
> static void __init replace_va_mapping(struct domain *d, l4_pgentry_t
> *l4start,
>
On 09/04/2020 09:06, Jan Beulich wrote:
On 09.04.2020 10:01, Julien Grall wrote:
Hi,
On 09/04/2020 07:30, Jan Beulich wrote:
On 09.04.2020 00:05, Julien Grall wrote:
I don't see why a new port may not also want
to go that route instead of the x86/Arm one.
I could accept that someone would
On 09.04.2020 10:56, Jürgen Groß wrote:
> On 09.04.20 10:00, Jan Beulich wrote:
>> On 09.04.2020 09:31, Jürgen Groß wrote:
>>> On 09.04.20 04:30, osstest service owner wrote:
flight 149520 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149520/
On 09.04.20 10:00, Jan Beulich wrote:
On 09.04.2020 09:31, Jürgen Groß wrote:
On 09.04.20 04:30, osstest service owner wrote:
flight 149520 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149520/
Regressions :-(
Tests which did not succeed and are blocking,
On 09.04.2020 10:01, Julien Grall wrote:
> Hi,
>
> On 09/04/2020 07:30, Jan Beulich wrote:
>> On 09.04.2020 00:05, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 07/04/2020 09:14, Jan Beulich wrote:
On 04.04.2020 15:10, Julien Grall wrote:
> From: Julien Grall
>
> Most of the
Hi,
On 09/04/2020 07:30, Jan Beulich wrote:
On 09.04.2020 00:05, Julien Grall wrote:
Hi Jan,
On 07/04/2020 09:14, Jan Beulich wrote:
On 04.04.2020 15:10, Julien Grall wrote:
From: Julien Grall
Most of the helpers to access guest memory are implemented the same way
on Arm and x86. The only
On 09.04.2020 09:31, Jürgen Groß wrote:
> On 09.04.20 04:30, osstest service owner wrote:
>> flight 149520 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/149520/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could
On 09.04.20 09:41, Jan Beulich wrote:
All,
the releases are due in a week or two. Please point out backports
you find missing from the respective staging branches, but which
you consider relevant. (Ian, I notice there haven't been any
tools side backports at all so far. Julien, Stefano - same
All,
the releases are due in a week or two. Please point out backports
you find missing from the respective staging branches, but which
you consider relevant. (Ian, I notice there haven't been any
tools side backports at all so far. Julien, Stefano - same for
Arm.)
Jan
flight 149550 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149550/
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
On 09.04.20 04:30, osstest service owner wrote:
flight 149520 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
Commit 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
introduced a regression for booting 32 bit Xen PV guests: the address
of the initial stack needs to be a virtual one.
Fixes: 2f62f36e62daec ("x86/xen: Make the boot CPU idle task reliable")
Signed-off-by: Juergen Gross
---
On 09.04.20 05:13, osstest service owner wrote:
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-pvshim
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree:
Adjusting recipient list (dropping David, new mail addresses for Wei and
Paul).
On 09.04.20 08:18, Christoph Hellwig wrote:
Hi Wei,
commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
multi-page ring") addes a use of vmap in what is now
xenbus_map_ring_valloc_hvm, and uses the
On 09.04.2020 00:05, Julien Grall wrote:
> Hi Jan,
>
> On 07/04/2020 09:14, Jan Beulich wrote:
>> On 04.04.2020 15:10, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Most of the helpers to access guest memory are implemented the same way
>>> on Arm and x86. The only differences are:
>>>
Hi Wei,
commit ccc9d90a9a8b5 ("xenbus_client: Extend interface to support
multi-page ring") addes a use of vmap in what is now
xenbus_map_ring_valloc_hvm, and uses the VM_IOREMAP flag that is
only really intended for implementing ioremap. Do you remember
what the reason is that this flag was
70 matches
Mail list logo
