flight 146800 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146800/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146799 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146799/
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
At 09:17 + on 06 Feb (1580980664), Durrant, Paul wrote:
> > -Original Message-
> > From: Jan Beulich
> > On 06.02.2020 09:28, Durrant, Paul wrote:
> > >> xen/arch/x86/mm/shadow/common.c | 2 +-
> George, Julien, Tim,
>
> Can I have acks or otherwise, please?
Acked-by: Tim Deegan
flight 146797 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146797/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
flight 146795 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146795/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146790 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
flight 146792 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146792/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
flight 146787 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146787/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 18 leak-check/check fail in 146777 pass in 146787
test-armhf-armhf-xl-arndale 7
flight 146794 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146794/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146793 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
Hi David,
Could you please send the series in a separate thread? So we don't mix
the two discussions (i.e merge and free on boot allocated page) together.
On 07/02/2020 15:57, David Woodhouse wrote:
From: David Woodhouse
Only PGC_state_offlining and PGC_state_offlined are valid in
Ok, thank you very much.
One more question - is that normal the /dev/drm/card0 device is mapped at
offset more then 4Gb?
Best regards,
Alexander
>Четверг, 6 февраля 2020, 11:20 +03:00 от Oleksandr Andrushchenko
>:
>
>On 2/5/20 8:59 PM, Santucco wrote:
>> Hello,
>> Ok, I commented out the
flight 146789 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
flight 146785 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
On Fri, 2020-02-07 at 17:06 +, David Woodhouse wrote:
> On 7 February 2020 16:40:01 GMT, "Xia, Hongyan" wrote:
> > On Fri, 2020-02-07 at 16:32 +, David Woodhouse wrote:
> > >
> > > ...
> > >
> > > Ideally not because init_heap_pages() then calls free_heap_pages()
> > > and the
flight 146780 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
flight 146784 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146784/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On Fri, Feb 7, 2020 at 10:16 AM Tamas K Lengyel wrote:
>
> On Fri, Feb 7, 2020 at 9:54 AM Jan Beulich wrote:
> >
> > On 07.02.2020 10:52, Roger Pau Monné wrote:
> > > On Fri, Feb 07, 2020 at 09:08:15AM +0100, Jan Beulich wrote:
> > >> On 06.02.2020 16:20, Jan Beulich wrote:
> > >>> ---
On Fri, Feb 7, 2020 at 9:54 AM Jan Beulich wrote:
>
> On 07.02.2020 10:52, Roger Pau Monné wrote:
> > On Fri, Feb 07, 2020 at 09:08:15AM +0100, Jan Beulich wrote:
> >> On 06.02.2020 16:20, Jan Beulich wrote:
> >>> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >>> @@
On 7 February 2020 16:40:01 GMT, "Xia, Hongyan" wrote:
>On Fri, 2020-02-07 at 16:32 +, David Woodhouse wrote:
>>
>> ...
>>
>> Ideally not because init_heap_pages() then calls free_heap_pages()
>> and the "recursion" is best avoided.
>
>Kind of depends on where we change its pg to
On Fri, 2020-02-07 at 16:32 +, David Woodhouse wrote:
>
> ...
>
> Ideally not because init_heap_pages() then calls free_heap_pages()
> and the "recursion" is best avoided.
Kind of depends on where we change its pg to initialised. If we do that
in free_heap_pages this does recurse, but if it
On 07.02.2020 10:52, Roger Pau Monné wrote:
> On Fri, Feb 07, 2020 at 09:08:15AM +0100, Jan Beulich wrote:
>> On 06.02.2020 16:20, Jan Beulich wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3037,9 +3037,8 @@ static int vmx_alloc_vlapic_mapping(stru
>>>
On Fri, 2020-02-07 at 15:57 +, David Woodhouse wrote:
> From: David Woodhouse
>
> ...
>
> Finally, make free_xenheap_pages() and free_domheap_pages() call
> through to init_heap_pages() instead of directly to free_heap_pages()
> in the case where pages are being free which have never passed
On 7 February 2020 16:30:04 GMT, "Xia, Hongyan" wrote:
>On Fri, 2020-02-07 at 15:57 +, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> ...
>>
>> Finally, make free_xenheap_pages() and free_domheap_pages() call
>> through to init_heap_pages() instead of directly to free_heap_pages()
From: David Woodhouse
It is possible for pages to enter general circulation without ever
being process by init_heap_pages().
For example, pages of the multiboot module containing the initramfs may
be assigned via assign_pages() to dom0 as it is created. And some code
including
From: David Woodhouse
Only PGC_state_offlining and PGC_state_offlined are valid in conjunction
with PGC_broken. The other two states (free and inuse) were never valid
for a broken page.
By folding PGC_broken in, we can have three bits for PGC_state which
allows up to 8 states, of which 6 are
On Wed, 2020-02-05 at 14:12 +, David Woodhouse wrote:
> I think we have a viable path to fixing that, by folding PGC_broken in to
> the state bits so that we can disambiguate. Will experiment.
Here, it looks something like this. First we fold PGC_broken into the
state bits giving us 8
flight 146777 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 146757
Tests which did
On Thu, Feb 06, 2020 at 01:24:52PM +, Andrew Cooper wrote:
> The local xc_hvm_param_deprecated_check() in libxc tries to guess Xen's
> behaviour for the MEMORY_EVENT params, but is wrong for the get side, where
> Xen would return 0 (which is also a bug). Delete the helper.
>
> In Xen,
On Fri, Feb 07, 2020 at 02:27:11PM +0100, Jan Beulich wrote:
> On 07.02.2020 13:20, Roger Pau Monné wrote:
> > On Thu, Feb 06, 2020 at 02:31:03PM +0100, Jan Beulich wrote:
> >> Checking just the first and last page is not sufficient (and redundant
> >> for single-page regions). As we don't need to
On Fri, Feb 07, 2020 at 02:25:17PM +0100, Jan Beulich wrote:
> Also adjust the comment ahead of e820_all_mapped() to clarify that the
> range is not inclusive at its end.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
>
On 07.02.2020 15:25, Wei Liu wrote:
> On Fri, Feb 07, 2020 at 02:25:17PM +0100, Jan Beulich wrote:
>> Also adjust the comment ahead of e820_all_mapped() to clarify that the
>> range is not inclusive at its end.
>>
>> Reported-by: Roger Pau Monné
>> Signed-off-by: Jan Beulich
>
> Reviewed-by:
From: Sergey Dyasli
Date: Fri, 7 Feb 2020 14:26:52 +
> From: Ross Lagerwall
>
> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
> non-power-of-two allocations are not aligned to the next power of 2 of
> the size. Therefore, handle grant copies that cross page
This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
CONFIG_KASAN=y. It has been used internally for some time now with good
results for finding memory corruption issues in Dom0 kernel.
Only Outline instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan:
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
non-power-of-two allocations are not aligned to the next power of 2 of
the size. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
Introduce and use xen_kasan_* functions that are needed to properly
initialise KASAN for Xen PV domains. Disable instrumentation for files
that are used by xen_start_kernel() before kasan_early_init() could
be called.
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
v2 --> v3: no changes
v1 --> v2: no changes
RFC --> v1:
- Slightly clarified the commit message
---
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table from inside Xen PV domains. Xen notices it during
kasan_populate_early_shadow():
(XEN) mm.c:3222:d155v0 mfn 3704b already pinned
This happens for kasan_early_shadow_pte when USE_SPLIT_PTE_PTLOCKS is
enabled.
On Fri, Feb 07, 2020 at 02:25:17PM +0100, Jan Beulich wrote:
> Also adjust the comment ahead of e820_all_mapped() to clarify that the
> range is not inclusive at its end.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
>
> --- a/xen/arch/x86/e820.c
> +++
On 07.02.2020 13:20, Roger Pau Monné wrote:
> On Thu, Feb 06, 2020 at 02:31:03PM +0100, Jan Beulich wrote:
>> Checking just the first and last page is not sufficient (and redundant
>> for single-page regions). As we don't need to care about IA64 anymore,
>> use an x86-specific function to get this
Also adjust the comment ahead of e820_all_mapped() to clarify that the
range is not inclusive at its end.
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -38,7 +38,7 @@ struct e820map e820;
struct e820map __initdata e820_raw;
On 07.02.20 12:09, Dario Faggioli wrote:
On Fri, 2020-02-07 at 08:24 +0100, Juergen Gross wrote:
When dumping the run queue information add some more data regarding
current and (if known) previous vcpu for each physical cpu.
Looks good to me.
Can we have, here in the changelog, a sample of
On 07.02.20 12:44, Roger Pau Monné wrote:
On Fri, Feb 07, 2020 at 10:25:05AM +0100, Jürgen Groß wrote:
On 07.02.20 09:49, Jan Beulich wrote:
On 07.02.2020 09:42, Jürgen Groß wrote:
On 07.02.20 09:23, Jan Beulich wrote:
On 07.02.2020 09:04, Jürgen Groß wrote:
On 06.02.20 15:02, Sergey Dyasli
flight 146778 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
On Thu, Feb 06, 2020 at 02:31:03PM +0100, Jan Beulich wrote:
> Checking just the first and last page is not sufficient (and redundant
> for single-page regions). As we don't need to care about IA64 anymore,
> use an x86-specific function to get this done without looping over each
> individual
On Fri, Feb 07, 2020 at 10:25:05AM +0100, Jürgen Groß wrote:
> On 07.02.20 09:49, Jan Beulich wrote:
> > On 07.02.2020 09:42, Jürgen Groß wrote:
> > > On 07.02.20 09:23, Jan Beulich wrote:
> > > > On 07.02.2020 09:04, Jürgen Groß wrote:
> > > > > On 06.02.20 15:02, Sergey Dyasli wrote:
> > > > > >
flight 146782 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On Fri, 2020-02-07 at 08:24 +0100, Juergen Gross wrote:
> When dumping the run queue information add some more data regarding
> current and (if known) previous vcpu for each physical cpu.
>
Looks good to me.
Can we have, here in the changelog, a sample of how the new output
looks like?
Regards
On Fri, 2020-02-07 at 10:24 +0100, Jan Beulich wrote:
> You don't mention any prereq patches, and I can't see any
> definition of KEXEC_TYPE_LIVE_UPDATE in the public headers.
> IOW I can't see how this patch would be able to not break
> the build on current staging. Please clarify.
I don't think
On 07.02.20 10:51, Jan Beulich wrote:
On 07.02.2020 10:25, Jürgen Groß wrote:
On 07.02.20 09:49, Jan Beulich wrote:
On 07.02.2020 09:42, Jürgen Groß wrote:
On 07.02.20 09:23, Jan Beulich wrote:
On 07.02.2020 09:04, Jürgen Groß wrote:
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020
On Fri, Feb 07, 2020 at 09:08:15AM +0100, Jan Beulich wrote:
> On 06.02.2020 16:20, Jan Beulich wrote:
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -3037,9 +3037,8 @@ static int vmx_alloc_vlapic_mapping(stru
> > share_xen_page_with_guest(pg, d, SHARE_rw);
>
On 07.02.2020 10:25, Jürgen Groß wrote:
> On 07.02.20 09:49, Jan Beulich wrote:
>> On 07.02.2020 09:42, Jürgen Groß wrote:
>>> On 07.02.20 09:23, Jan Beulich wrote:
On 07.02.2020 09:04, Jürgen Groß wrote:
> On 06.02.20 15:02, Sergey Dyasli wrote:
>> On 06/02/2020 11:05, Sergey Dyasli
On 07.02.20 09:49, Jan Beulich wrote:
On 07.02.2020 09:42, Jürgen Groß wrote:
On 07.02.20 09:23, Jan Beulich wrote:
On 07.02.2020 09:04, Jürgen Groß wrote:
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20
On 07.02.2020 10:00, Varad Gautam wrote:
> Do not -EINVAL on loading/execing an image if kexec type is
> KEXEC_TYPE_LIVE_UPDATE.
>
> Signed-off-by: Varad Gautam
> CC: David Woodhouse
Please Cc maintainers on patches.
> --- a/xen/common/kimage.c
> +++ b/xen/common/kimage.c
> @@ -421,6 +421,7
Do not -EINVAL on loading/execing an image if kexec type is
KEXEC_TYPE_LIVE_UPDATE.
Signed-off-by: Varad Gautam
CC: David Woodhouse
---
xen/common/kimage.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 86d2797..599aa74 100644
---
Any thoughts on this are appreciated.
Thanks,
Alex
On 30.01.2020 15:07, Alexandru Stefan 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
flight 146779 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
On 07.02.2020 09:42, Jürgen Groß wrote:
> On 07.02.20 09:23, Jan Beulich wrote:
>> On 07.02.2020 09:04, Jürgen Groß wrote:
>>> On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
> On 06/02/2020 09:57, Jürgen Groß wrote:
>> On 05.02.20 17:03, Sergey
On 07.02.20 09:23, Jan Beulich wrote:
On 07.02.2020 09:04, Jürgen Groß wrote:
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch
On 07.02.2020 09:04, Jürgen Groß wrote:
> On 06.02.20 15:02, Sergey Dyasli wrote:
>> On 06/02/2020 11:05, Sergey Dyasli wrote:
>>> On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
> Hello,
>
> I'm currently investigating a Live-Patch application
On 06.02.2020 16:20, Jan Beulich wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3037,9 +3037,8 @@ static int vmx_alloc_vlapic_mapping(stru
> share_xen_page_with_guest(pg, d, SHARE_rw);
> d->arch.hvm.vmx.apic_access_mfn = mfn;
>
> -return
On 06.02.20 15:02, Sergey Dyasli wrote:
On 06/02/2020 11:05, Sergey Dyasli wrote:
On 06/02/2020 09:57, Jürgen Groß wrote:
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I
On 06.02.2020 19:46, Jason Andryuk wrote:
> On Thu, Feb 6, 2020 at 8:33 AM Jan Beulich wrote:
>>
>> Consistently use [,] range representation, shrink leading double blanks
>> to a single one, and slightly adjust text in some cases.
>>
>> Signed-off-by: Jan Beulich
>>
>> ---
63 matches
Mail list logo
