flight 160139 xen-4.12-testing real [real]
flight 160149 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160139/
http://logs.test-lab.xenproject.org/osstest/logs/160149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 160134 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On Sat, 27 Feb 2021, Julien Grall wrote:
> (+ Dario and George)
>
> Hi Stefano,
>
> I have added Dario and George to get some inputs from the scheduling part.
>
> On 27/02/2021 01:58, Stefano Stabellini wrote:
> > On Fri, 26 Feb 2021, Julien Grall wrote:
> > > From: Julien Grall
> > >
> > > A
On 3/19/21 4:01 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Newer Xen versions expose two Xen feature flags to tell us if the domain
> is directly mapped or not. Only when a domain is directly mapped it
> makes sense to enable swiotlb-xen on ARM.
>
> Introduce a function on ARM
flight 160132 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
From: Stefano Stabellini
Newer Xen versions expose two Xen feature flags to tell us if the domain
is directly mapped or not. Only when a domain is directly mapped it
makes sense to enable swiotlb-xen on ARM.
Introduce a function on ARM to check the new Xen feature flags and also
to deal with the
On Sat, 13 Mar 2021, Julien Grall wrote:
> Hi Jan & Stefano,
>
> On 08/03/2021 09:49, Jan Beulich wrote:
> > All,
> >
> > the release is overdue (my apologies). Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant.
> > > Ones th
Hi Stefano,
On 19/03/2021 17:53, Stefano Stabellini wrote:
On Fri, 19 Mar 2021, Boris Ostrovsky wrote:
On 3/18/21 7:28 PM, Stefano Stabellini wrote:
So, I'll follow you suggestion, keep the x86 side named as it is today,
and provide a tiny wrapper so that we can still have an arch-neutral
xen
On 19/03/2021 14:02, Jan Beulich wrote:
> On 19.03.2021 12:44, Andrew Cooper wrote:
>> On 08/03/2021 09:49, Jan Beulich wrote:
>>> the release is overdue (my apologies). Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant.
>>>
>>
On 3/19/21 1:53 PM, Stefano Stabellini wrote:
> On Fri, 19 Mar 2021, Boris Ostrovsky wrote:
>> On 3/18/21 7:28 PM, Stefano Stabellini wrote:
>>> So, I'll follow you suggestion, keep the x86 side named as it is today,
>>> and provide a tiny wrapper so that we can still have an arch-neutral
>>> xen
flight 160131 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160131/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eb07bfb09ef5483ad58ed0eba713f32fb0c909f9
baseline version:
ovmf 9fd7e88c23f6fb056d25f
On Fri, 19 Mar 2021, Boris Ostrovsky wrote:
> On 3/18/21 7:28 PM, Stefano Stabellini wrote:
> >
> > So, I'll follow you suggestion, keep the x86 side named as it is today,
> > and provide a tiny wrapper so that we can still have an arch-neutral
> > xen_swiotlb_detect function (on x86 just calls pci
flight 160135 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
flight 160130 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160130/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 160120
Tests which did not succeed
On 3/18/21 7:28 PM, Stefano Stabellini wrote:
>
> So, I'll follow you suggestion, keep the x86 side named as it is today,
> and provide a tiny wrapper so that we can still have an arch-neutral
> xen_swiotlb_detect function (on x86 just calls pci_xen_swiotlb_detect.)
But now on x86 side we end u
On 19/03/2021 13:56, Jan Beulich wrote:
> On 19.03.2021 13:59, Andrew Cooper wrote:
>> On 16/03/2021 16:58, Jan Beulich wrote:
>>> On 16.03.2021 17:18, Andrew Cooper wrote:
In hindsight, this was a poor move. Some of these MSRs require probing
for,
causing unhelpful spew into xl dm
On 19.03.2021 12:44, Andrew Cooper wrote:
> On 08/03/2021 09:49, Jan Beulich wrote:
>> the release is overdue (my apologies). Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant.
>>
>> Ones that I have queued already, but which had
On 19.03.2021 13:59, Andrew Cooper wrote:
> On 16/03/2021 16:58, Jan Beulich wrote:
>> On 16.03.2021 17:18, Andrew Cooper wrote:
>>> In hindsight, this was a poor move. Some of these MSRs require probing for,
>>> causing unhelpful spew into xl dmesg, as well as spew from unit tests
>>> explicitly
Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for
4.13.3)"):
> The effects of the bug were twofold:
> * A client actually requesting Reset_watches has the request rejected
> * A client actually requesting Restrict got Reset_watches instead
>
> We spotted the bug when
Ian Jackson writes ("Re: Call for tools backports (was Re: preparations for
4.13.3)"):
> Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for
> 4.13.3)"):
> > These are general backport requests, not specifically for 4.13
>
> Thanks!
I have now applied these, I think ea
On 19/03/2021 13:21, Ian Jackson wrote:
>> a6ed77f1e033 - oxenstored: fix ABI breakage introduced in Xen 4.9.0
>>
>> The final one is an ABI change, but fixing a regression.
> I'm not sure about this but I think the effect can only be on
> "Reset_watches" ? I guess I will take it.
The effects of
On 19.03.2021 13:45, Dylanger Daly wrote:
> Hi Everyone, I've just confirmed only `tsc=unstable` is required,
> that specific change has fixed the issues I was having on the
> Lenovo X13, I assume this is because Lenovo's Clock isn't correct?
Hard to tell without knowing what actually went wrong.
On 17/03/2021 08:32, Roger Pau Monné wrote:
> On Tue, Mar 16, 2021 at 09:20:10PM +, Andrew Cooper wrote:
>> On 16/03/2021 16:56, Roger Pau Monné wrote:
>>> On Tue, Mar 16, 2021 at 04:18:44PM +, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
>>> Thanks!
>>>
---
CC: Jan Beu
Andrew Cooper writes ("Re: Call for tools backports (was Re: preparations for
4.13.3)"):
> These are general backport requests, not specifically for 4.13
Thanks!
> d92ba1aa7cf8 - tools/ocaml: libxb: Harden stub_header_of_string()
> 59b087e39544 - tools/ocaml: Fix stubs build when OCaml has been
On 17/03/2021 08:52, Roger Pau Monné wrote:
> On Tue, Mar 16, 2021 at 04:18:43PM +, Andrew Cooper wrote:
>> staging was not impacted by XSA-351 at the time of release, due to c/s
>> 322ec7c89f and 84e848fd7a which disallows read access by default.
>>
>> Forward port the XSA-351 changes to make
On 18/03/2021 09:35, Jan Beulich wrote:
> On 17.03.2021 14:37, Ian Jackson wrote:
>> I have read this thread and with my release manager hat on I feel
>> confused and/or ignorant.
>>
>> Patch 3/ has a good explanation of what the problem is it is
>> addressing and why this is important for 4.15. B
On 16/03/2021 16:58, Jan Beulich wrote:
> On 16.03.2021 17:18, Andrew Cooper wrote:
>> In hindsight, this was a poor move. Some of these MSRs require probing for,
>> causing unhelpful spew into xl dmesg, as well as spew from unit tests
>> explicitly checking behaviour.
> I can indeed see your poin
flight 160129 xen-4.13-testing real [real]
flight 160140 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160129/
http://logs.test-lab.xenproject.org/osstest/logs/160140/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Hi Everyone, I've just confirmed only `tsc=unstable` is required, that specific
change has fixed the issues I was having on the Lenovo X13, I assume this is
because Lenovo's Clock isn't correct?
> Right. Also, isn't hpetbroadcast set to 0 by default already?
>
> Dario
> -
On Thu, Mar 18, 2021 at 5:36 PM Tamas K Lengyel wrote:
>
> When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value.
> Some
> toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum
> addressable physical memory in the VM and for forks that have not yet been
>
On Fri, Mar 19, 2021 at 7:25 AM Jan Beulich wrote:
>
> On 19.03.2021 12:06, Tamas K Lengyel wrote:
> > On Fri, Mar 19, 2021, 6:23 AM Jan Beulich wrote:
> >
> >> On 18.03.2021 22:36, Tamas K Lengyel wrote:
> >>> --- a/xen/arch/x86/mm/mem_sharing.c
> >>> +++ b/xen/arch/x86/mm/mem_sharing.c
> >>> @@
If we schedule, and the current vCPU continues to run, its statistical
load is not properly updated, resulting in something like this, even if
all the 8 vCPUs are 100% busy:
(XEN) Runqueue 0:
(XEN) [...]
(XEN) aveload= 2097152 (~800%)
(XEN) [...]
(XEN) Domain: 0 w 256 c 0 v 8
(XEN)
On 19.03.2021 12:57, Andrew Cooper wrote:
> Do we want to backport the -Og fixes so we can get ABI checking working?
Do we have a finalized picture of how this checking is going to
work? I was under the impression that this is still in flux, in
which case I'm not convinced of backporting changes j
On 17/03/2021 14:55, Ian Jackson wrote:
> Julien Grall writes ("Re: preparations for 4.13.3"):
>> On 08/03/2021 09:49, Jan Beulich wrote:
>>> All,
>>>
>>> the release is overdue (my apologies). Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you c
On 19.03.21 12:50, Luca Fancellu wrote:
Hi Juergen,
Could you confirm that back porting this two serie to the linux kernel 5.10:
https://patchwork.kernel.org/project/xen-devel/cover/20201210192536.118432...@linutronix.de/
I don't see why this one would be needed?
https://patchwork.kernel.or
Hi Juergen,
Could you confirm that back porting this two serie to the linux kernel 5.10:
https://patchwork.kernel.org/project/xen-devel/cover/20201210192536.118432...@linutronix.de/
https://patchwork.kernel.org/project/xen-devel/cover/20210306161833.4552-1-jgr...@suse.com/
Is needed to remove th
On 08/03/2021 09:49, Jan Beulich wrote:
> All,
>
> the release is overdue (my apologies). Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant.
>
> Ones that I have queued already, but which hadn't passed the push
> gate to master yet
On 19.03.2021 12:06, Tamas K Lengyel wrote:
> On Fri, Mar 19, 2021, 6:23 AM Jan Beulich wrote:
>
>> On 18.03.2021 22:36, Tamas K Lengyel wrote:
>>> --- a/xen/arch/x86/mm/mem_sharing.c
>>> +++ b/xen/arch/x86/mm/mem_sharing.c
>>> @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, str
On Fri, Mar 19, 2021, 6:23 AM Jan Beulich wrote:
> On 18.03.2021 22:36, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, struct
> domain *d)
> > return rc;
> >
> >
Hi Stefano,
Gentle ping. On IRC, Jan pointed out that he would like to realize the
4.13.3 pretty soon.
Cheers,
On 13/03/2021 15:29, Julien Grall wrote:
Hi Jan & Stefano,
On 08/03/2021 09:49, Jan Beulich wrote:
All,
the release is overdue (my apologies). Please point out backports
you find
Hi Ian,
On 17/03/2021 14:55, Ian Jackson wrote:
Julien Grall writes ("Re: preparations for 4.13.3"):
On 08/03/2021 09:49, Jan Beulich wrote:
All,
the release is overdue (my apologies). Please point out backports
you find missing from the respective staging branches, but which
you consider rel
On 18.03.2021 22:36, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, struct
> domain *d)
> return rc;
>
> copy_tsc(cd, d);
> +p2m_get_hostp2m(cd)->max_mapped_p
On 10.03.21 20:37, Igor Druzhinin wrote:
On 30.01.21 19:53, Roman Shaposhnik wrote:
On Fri, Jan 29, 2021 at 11:28 PM Jürgen Groß wrote:
On 29.01.21 21:12, Roman Shaposhnik wrote:
Hi!
I'm trying to see how much mileage I can get out of
crash(1) 7.2.8 (based on gdb 7.6) when it comes to analy
On Tue, 2021-03-16 at 09:02 +0100, Jan Beulich wrote:
> On 16.03.2021 03:10, Dylanger Daly wrote:
> > I just wanted to close this off and let everyone know the issue
> > ended up being a faulty/misconfigured HPET clock.
> >
> > Appending `clocksource=tsc tsc=unstable hpetbroadcast=0` to Xen's
> >
flight 160128 xen-4.12-testing real [real]
flight 160137 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160128/
http://logs.test-lab.xenproject.org/osstest/logs/160137/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
45 matches
Mail list logo
