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
---
a
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:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd
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
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
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 fo
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 no
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 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 helpers
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,
including
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/
Regressi
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 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,
>
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 inside
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
test-amd64-i386-xl-
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]
http://logs.test-lab.xenproject.org/osstest/logs/1
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 r
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,
>>>
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 fi
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, p2m_ra
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 c
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 14
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 scheduler_disab
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 in
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 IR
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
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
Signed-
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 ++--
console/xenbus.c
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")
Signed-off-b
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")
Signed-
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
> >
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
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 pa
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: d225f4012d69a
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: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
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:
> - send_domain_m
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 t
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 which
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 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 pr
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 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 and
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 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 specify
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 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" c
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
> > > > > + * - max_maptrack_frames
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
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é
Review
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 Monné
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):
x8
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.
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 1
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 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 di
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 12f0c6
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,
>^~
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 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: ‘HVM_P
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 ‘copy_special_pa
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 buil
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 An
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 git://xenbits.xen.org/qemu-xen-traditional
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
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
test-amd64-i386-xl
> 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.
> T
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.7-rc1b-tag
xen: branch for v5.7-rc1b
This is a second batch of Xen related patches:
- two cleanup patches
- a patch to fix a boot regression introduced earlier in 5.7
- a patch to
On 10.04.2020 06:10, Tian, Kevin wrote:
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a3d115b650..375e9cf368 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4511,6 +4511,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_get_mem_access:
case
Are there any more r-b needed for this patch?
Thanks,
Alex
On 30.03.2020 09:54, Alexandru Isaila wrote:
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
69 matches
Mail list logo
