On Fri, Sep 17, 2021 at 05:46:23PM +0200, Roger Pau Monne wrote:
> Exploiting the talloc clean up routines to close the Xen interfaces
> is cumbersome, specially when atexit can be used to the same effect.
>
> Convert xc and gnttab to use atexit which allows to drop one
> indirection from the
On 17.09.2021 15:26, Andrew Cooper wrote:
> On 17/09/2021 13:58, Jan Beulich wrote:
>> On 17.09.2021 10:45, Andrew Cooper wrote:
>>> --- a/xen/common/trace.c
>>> +++ b/xen/common/trace.c
>>> @@ -686,22 +686,21 @@ void __trace_var(u32 event, bool_t cycles, unsigned
>>> int extra,
>>> unsigned
On 17.09.21 17:46, Roger Pau Monne wrote:
Restore the previous way of mapping the xenstore ring using foreign
memory. Use xenforeignmemory instead of libxc in order to avoid adding
another dependency on a unstable interface.
Mapping a guest page via xenforeignmemory is no good move IMO. A
> On 20 Sep 2021, at 08:26, Roger Pau Monne wrote:
>
> On Fri, Sep 17, 2021 at 06:06:42PM +0200, Christian Lindig wrote:
>>
>>
>>> On 17 Sep 2021, at 16:46, Roger Pau Monne wrote:
>>>
>>> Hello,
>>>
>>> The first two patches of this series allows setting the preisoutly host
>>> wide
I think it contend on page insertion into free pages list. But I don't confirm or denied this yet. I'm new in hypervisors...11:19, 20 сентября 2021 г., Jan Beulich :On 17.09.2021 18:01, Julien Grall wrote: I will quote what Hongyan wrote back on the first report: " The best solution is to make
On 17.09.2021 10:45, Andrew Cooper wrote:
> It is pointless to write all 6 entries and only consume the useful subset.
> bloat-o-meter shows quite how obscene the overhead is in vmx_vmexit_handler(),
> weighing in at 11% of the function arranging unread zeroes on the stack, and
> 8% for
On 17.09.2021 10:45, Andrew Cooper wrote:
> There is no need for bitfields anywhere - use more sensible types. There is
> also no need to cast 'd' to (unsigned char *) before passing it to a function
> taking void *.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan
On Fri, Sep 17, 2021 at 06:06:42PM +0200, Christian Lindig wrote:
>
>
> > On 17 Sep 2021, at 16:46, Roger Pau Monne wrote:
> >
> > Hello,
> >
> > The first two patches of this series allows setting the preisoutly host
> > wide command line `gnttab` option on a per domain basis. That means
> >
On 17.09.2021 16:21, Tamas K Lengyel wrote:
> On Fri, Sep 17, 2021 at 3:26 AM Jan Beulich wrote:
>>
>> On 16.09.2021 17:04, Tamas K Lengyel wrote:
>>> During fork reset operation the parent domain doesn't need to be gathered
>>> using
>>> rcu_lock_live_remote_domain_by_id as the fork reset
On 17.09.2021 18:01, Julien Grall wrote:
> I will quote what Hongyan wrote back on the first report:
>
> "
> The best solution is to make the heap scalable instead of a global
> lock, but that is not going to be trivial.
>
> Of course, another solution is to keep the domctl lock dropped in
>
On 17.09.2021 10:45, Andrew Cooper wrote:
> * Delete trailing whitespace
> * Replace an opencoded DIV_ROUND_UP()
> * Drop bogus smp_rmb() - spin_lock_irqsave() has full smp_mb() semantics.
>
> Signed-off-by: Andrew Cooper
Largely
Reviewed-by: Jan Beulich
One remark:
> @@ -717,9 +713,6 @@
On 17.09.21 17:46, Roger Pau Monne wrote:
Exploiting the talloc clean up routines to close the Xen interfaces
is cumbersome, specially when atexit can be used to the same effect.
Convert xc and gnttab to use atexit which allows to drop one
indirection from the storing variables.
No functional
flight 165124 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 165121
build-arm64-xsm4
On 17/09/2021 16:46, Roger Pau Monne wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 7f8456c50e..fe2201fca1 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -96,6 +96,14 @@ struct xen_domctl_createdomain {
> int32_t
Hello,
originally I was puzzled to find that libxenguest's setting up of
struct hvm_start_info didn't have any explicit clearing of reserved
fields. Turns out the memory gets zeroed right after allocation.
Isn't this a waste of bandwidth particularly when considering the
kernel, initrd, or P2M
Commit 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a
workqueue") switched the Xen balloon driver to use a kernel thread.
Unfortunately the patch omitted to call try_to_freeze() or to use
wait_event_freezable_timeout(), causing a system suspend to fail.
Fixes: 8480ed9c2bbd56
On Mon, Sep 13, 2021 at 08:41:47AM +0200, Jan Beulich wrote:
> Without holding appropriate locks, attempting to remove a prior mapping
> of the underlying page is pointless, as the same (or another) mapping
> could be re-established by a parallel request on another vCPU. Move the
> code to Arm's
On 20/09/2021 09:00, Jan Beulich wrote:
> On 17.09.2021 15:26, Andrew Cooper wrote:
>> On 17/09/2021 13:58, Jan Beulich wrote:
>>> On 17.09.2021 10:45, Andrew Cooper wrote:
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -686,22 +686,21 @@ void __trace_var(u32 event, bool_t
Jan Beulich writes ("[PATCH] page-alloc: further adjust assign_page{,s}()"):
> The on-commit editing of 5260e8fb93f0 ("xen: re-define assign_pages and
> introduce a new function assign_page") didn't go quite far enough: A
> local variable and a function argument also would have wanted adjusting.
Roger Pau Monne writes ("[PATCH 3/6] tools/console: use xenforeigmemory to map
console ring"):
> This patch replaces the usage of xc_map_foreign_range with
> xenforeignmemory_map from the stable xenforeignmemory library. Note
> there are still other uses of libxc functions which prevents removing
On Mon, Sep 20, 2021 at 10:24:45AM +0200, Juergen Gross wrote:
> On 17.09.21 17:46, Roger Pau Monne wrote:
> > Restore the previous way of mapping the xenstore ring using foreign
> > memory. Use xenforeignmemory instead of libxc in order to avoid adding
> > another dependency on a unstable
On Mon, Sep 20, 2021 at 11:22:15AM +0200, Juergen Gross wrote:
> On 17.09.21 17:46, Roger Pau Monne wrote:
> > Exploiting the talloc clean up routines to close the Xen interfaces
> > is cumbersome, specially when atexit can be used to the same effect.
> >
> > Convert xc and gnttab to use atexit
On 20/09/2021 10:05, Jan Beulich wrote:
> On 17.09.2021 10:45, Andrew Cooper wrote:
>> It is pointless to write all 6 entries and only consume the useful subset.
>> bloat-o-meter shows quite how obscene the overhead is in
>> vmx_vmexit_handler(),
>> weighing in at 11% of the function arranging
On 20.09.21 12:57, Ian Jackson wrote:
Roger Pau Monné writes ("Re: [PATCH 4/6] tools/xenstored: use atexit to close
interfaces"):
On Mon, Sep 20, 2021 at 11:22:15AM +0200, Juergen Gross wrote:
Could you please add closing of xce_handle(), too?
Sure, I somehow assumed there was a reason for
On Mon, Sep 20, 2021 at 10:32:24AM +0100, Andrew Cooper wrote:
> On 17/09/2021 16:46, Roger Pau Monne wrote:
> > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> > index 7f8456c50e..fe2201fca1 100644
> > --- a/xen/include/public/domctl.h
> > +++
Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
reservations") introduced early_reserve_memory() to do all needed
initial memblock_reserve() calls in one function. Unfortunately the
call of early_reserve_memory() is done too late for Xen dom0, as in
some cases a Xen hook called by
On 17.09.21 12:43, Jan Beulich wrote:
The primary intention really was the last patch, there you go (on top
of what is already in xen/tip.git for-linus-5.15) ...
1: swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests
2: PCI: only build xen-pcifront in PV-enabled environments
3:
The initial observation was that in PV mode under Xen 32-bit user space
didn't work anymore. Attempts of system calls ended in #GP(0x402). All
of the sudden the vector 0x80 handler was not in place anymore. As it
turns out up to 5.13 redundant initialization did occur: Once from
Roger Pau Monne writes ("[PATCH DNA 5/6] tools/xenstored: restore support for
mapping ring as foreign memory"):
> Restore the previous way of mapping the xenstore ring using foreign
> memory. Use xenforeignmemory instead of libxc in order to avoid adding
> another dependency on a unstable
On 20.09.21 12:34, Ian Jackson wrote:
Roger Pau Monne writes ("[PATCH 4/6] tools/xenstored: use atexit to close
interfaces"):
Exploiting the talloc clean up routines to close the Xen interfaces
is cumbersome, specially when atexit can be used to the same effect.
Wait, what ? Why do we need
As a reminder:
All new features and substantial refactorings, intended for Xen 4.16,
must be posted by xen-devel by the end of this coming Friday, the 24th
of Septebmer.
Patch series first posted after that date will be eligible for
subsequent Xen releases, but not Xen 4.16.
Full release
On Mon, 20 Sep 2021 13:05:25 +0100,
Paolo Bonzini wrote:
>
> On 17/09/21 09:28, Peter Zijlstra wrote:
> >> In theory, I like the idea of burying intel_pt inside x86 (and even in
> >> Intel+VMX code for the most part), but the actual implementation is a
> >> bit gross. Because of the whole "KVM
Juergen Gross writes ("Re: [PATCH 4/6] tools/xenstored: use atexit to close
interfaces"):
> They are. I checked when implementing LU and just rechecked.
>
> The event-channel fd is opened explicitly without CLOEXEC in order
> to support LU (the new xenstored won't open it again, but gets its
>
flight 165128 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165128/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 20.09.21 12:42, Roger Pau Monné wrote:
On Mon, Sep 20, 2021 at 10:24:45AM +0200, Juergen Gross wrote:
On 17.09.21 17:46, Roger Pau Monne wrote:
Restore the previous way of mapping the xenstore ring using foreign
memory. Use xenforeignmemory instead of libxc in order to avoid adding
another
flight 165125 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
flight 165126 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165126/
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-i386-libvirt
On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
Hello, Stefano!
On 18.09.21 00:45, Stefano Stabellini wrote:
Hi Oleksandr,
Why do you want to enable pciback on ARM? Is it only to "disable" a PCI
device in Dom0 so that it can be safely assigned to a DomU?
Not only that
I am asking because
On 20.09.2021 12:20, Roger Pau Monné wrote:
> On Mon, Sep 13, 2021 at 08:41:47AM +0200, Jan Beulich wrote:
>> --- a/xen/include/asm-arm/grant_table.h
>> +++ b/xen/include/asm-arm/grant_table.h
>> @@ -71,11 +71,17 @@ int replace_grant_host_mapping(unsigned
>> XFREE((gt)->arch.status_gfn);
On 20.09.2021 17:44, Ian Jackson wrote:
> Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
>> As per
>>
>> Sep 15 14:44:55.502598 [ 1613.322585] Mem-Info:
>> Sep 15 14:44:55.502643 [ 1613.324918] active_anon:5639 inactive_anon:15857
>> isolated_anon:0
>> Sep 15
Roger Pau Monne writes ("[PATCH 4/6] tools/xenstored: use atexit to close
interfaces"):
> Exploiting the talloc clean up routines to close the Xen interfaces
> is cumbersome, specially when atexit can be used to the same effect.
Wait, what ? Why do we need to do this at all ? xenstored can't
Hello,
I notice that from its introduction in 3.19 this function simply clears
message address and data. I wonder in how far this is "deactivation":
Aiui the device might still signal interrupts this way, by writing
32 bits of zeroes to address zero. (That's not going to result in an
interrupt,
Hello, Juergen!
On 20.09.21 14:30, Juergen Gross wrote:
> On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
>> Hello, Stefano!
>>
>> On 18.09.21 00:45, Stefano Stabellini wrote:
>>> Hi Oleksandr,
>>>
>>> Why do you want to enable pciback on ARM? Is it only to "disable" a PCI
>>> device in Dom0 so
On 17/09/21 09:28, Peter Zijlstra wrote:
In theory, I like the idea of burying intel_pt inside x86 (and even in
Intel+VMX code for the most part), but the actual implementation is a
bit gross. Because of the whole "KVM can be a module" thing,
ARGH!! we should really fix that. I've heard other
On 20.09.2021 13:02, Andrew Cooper wrote:
> On 20/09/2021 10:05, Jan Beulich wrote:
>> On 17.09.2021 10:45, Andrew Cooper wrote:
>>> It is pointless to write all 6 entries and only consume the useful subset.
>>> bloat-o-meter shows quite how obscene the overhead is in
>>> vmx_vmexit_handler(),
On Mon, 20 Sep 2021 14:18:30 +0100,
Paolo Bonzini wrote:
>
> On 20/09/21 14:22, Marc Zyngier wrote:
> >> I think that's only ARM, and even then it is only because of
> >> limitations of the hardware which mostly apply only if VHE is not in
> >> use.
> >>
> >> If anything, it's ARM that should
During fork reset operation the parent domain doesn't need to be gathered using
rcu_lock_live_remote_domain_by_id, the fork already has the parent pointer.
Signed-off-by: Tamas K Lengyel
---
v2: NULL the parent pointer early in the fork error path
---
xen/arch/x86/mm/mem_sharing.c | 15
On 20.09.2021 15:40, Tamas K Lengyel wrote:
> During fork reset operation the parent domain doesn't need to be gathered
> using
> rcu_lock_live_remote_domain_by_id, the fork already has the parent pointer.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
On 16.09.21 17:05, Jan Beulich wrote:
Just after having obtained the pointer from kzalloc() there's no reason
at all to set part of the area to all zero yet another time. Similarly
there's no point explicitly clearing "ldt_ents".
Signed-off-by: Jan Beulich
Pushed to xen/tip.git
On 17.09.21 08:13, Jan Beulich wrote:
While working on XSA-361 and its follow-ups, I failed to spot another
place where the kernel mapping part of an operation was not treated the
same as the user space part. Detect and propagate errors and add a 2nd
pr_debug().
Signed-off-by: Jan Beulich
Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> As per
>
> Sep 15 14:44:55.502598 [ 1613.322585] Mem-Info:
> Sep 15 14:44:55.502643 [ 1613.324918] active_anon:5639 inactive_anon:15857
> isolated_anon:0
> Sep 15 14:44:55.514480 [ 1613.324918] active_file:13286
Roger Pau Monné writes ("Re: [PATCH 4/6] tools/xenstored: use atexit to close
interfaces"):
> On Mon, Sep 20, 2021 at 11:22:15AM +0200, Juergen Gross wrote:
> > Could you please add closing of xce_handle(), too?
>
> Sure, I somehow assumed there was a reason for not closing it related
> to live
On 20/09/21 14:22, Marc Zyngier wrote:
I think that's only ARM, and even then it is only because of
limitations of the hardware which mostly apply only if VHE is not in
use.
If anything, it's ARM that should support module build in VHE mode
(Linux would still need to know whether it will be
flight 165127 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 165119
build-arm64-xsm
The feature is x86 and pv-dom0 specific, and each architecture's main trace.h
files are empty. Don't force all new architectures to create an empty file.
While moving the declaration of tb_init_done, change from int to bool.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Use more appropriate types.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
v2:
* New
---
xen/arch/x86/irq.c | 4 +-
xen/arch/x86/mm/p2m-pt.c | 6 +-
xen/arch/x86/mm/shadow/multi.c | 2 +-
xen/arch/x86/pv/trace.c| 159
On 9/20/21 12:15 PM, Jan Beulich wrote:
> The initial observation was that in PV mode under Xen 32-bit user space
> didn't work anymore. Attempts of system calls ended in #GP(0x402). All
> of the sudden the vector 0x80 handler was not in place anymore. As it
> turns out up to 5.13 redundant
xenlockprof with my patch (some zero lines have been removed for brevity): $ sudo xenlockprof -r ; for i in $(seq 1 5) ; do time sudo /usr/lib/xen-4.14/bin/xl destroy test-vm-${i} & done ; wait $(jobs -p) ; sudo xenlockprof real 0m1,224suser 0m0,013ssys 0m0,710s real 0m1,262suser
This will be used to clean up mess of macros which exists throughout the
codebase.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
v2.1:
* New
---
xen/include/xen/trace.h | 24
On 9/20/21 6:03 AM, Juergen Gross wrote:
> Commit 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a
> workqueue") switched the Xen balloon driver to use a kernel thread.
> Unfortunately the patch omitted to call try_to_freeze() or to use
> wait_event_freezable_timeout(), causing a
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano
It is pointless to write all 6 entries and only consume the useful subset.
bloat-o-meter shows quite how obscene the overhead is in vmx_vmexit_handler(),
weighing in at 12% of the function arranging unread zeroes on the stack, and
8% for svm_vmexit_handler().
add/remove: 0/0 grow/shrink: 0/20
Most uses of bitfields and __packed are unnecessary. There is also no need to
cast 'd' to (unsigned char *) before passing it to a function taking void *.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei
* Delete trailing whitespace
* Replace an opencoded DIV_ROUND_UP()
* Drop bogus smp_rmb() - spin_lock_irqsave() has full smp_mb() semantics.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Dario
All three of these records have tail padding, leaking stack rubble into the
trace buffer. Introduce an explicit _pad field and have the compiler zero the
padding automatically.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC:
In the case that 'extra' isn't a multiple of uint32_t, the calculation rounds
the number of bytes up, causing later logic to read unrelated bytes beyond the
end of the object.
Also, asserting that the object is within TRACE_EXTRA_MAX, but truncating it
in release builds is rude. Instead, reject
Four TRC_MEM_* records supply custom structures with tail padding, leaking
stack rubble into the trace buffer. Three of the records were fine in 32-bit
builds of Xen, due to the relaxed alignment of 64-bit integers, but
POD_SUPERPAGE_SPLITER was broken right from the outset.
We could pack the
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan
Patches 1-3 fix bugs causing uninitialised stack to leak into the trace
buffers. Xentrace is a developer/debugging activity restricted to fully
privileged entities, so the leaking of uninitialised stack contents is not a
security concern here.
Patches 4 and 5 are cleanup worthy of backporting,
1) vpic_ack_pending_irq() calls vlapic_accept_pic_intr() twice, once in the
TRACE_2D() instantiation and once "for real". Make the call only once.
2) vlapic_accept_pic_intr() similarly calls __vlapic_accept_pic_intr() twice,
although this is more complicated to disentangle.
v cannot be
This entire file is pv-only, and not excluded from the build by
CONFIG_TRACEBUFFER. Move it into the pv/ directory, build it conditionally,
and drop unused includes.
Also move the contents of asm/trace.h to asm/pv/trace.h to avoid the functions
being declared across the entire hypervisor.
One
On 17.09.21 01:35, Stefano Stabellini wrote:
Hi Stefano
On Fri, 10 Sep 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings
On 20/09/21 15:40, Marc Zyngier wrote:
At least not before we
declare the arm64 single kernel image policy to be obsolete.
--verbose please.:) I am sure you're right, but I don't understand
the link between the two.
To start making KVM/arm64 modular, you'd have to build it such as
there is
(Almost) no functional change.
irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the 'me'
local variable which manifests as a minor code improvement. All other
differences in the compiled binary are to do with line numbers changing.
Some conversion notes:
*
With all users updated to the new API, drop the old API. This includes all of
asm/hvm/trace.h, which allows us to drop some includes.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
v2.1:
* New
---
The mapping interface can only be used by x86 PV guests.
This can and should be fixed by changing to an acquire_resource() based
interface, which is compatbile with x86 PVH and ARM dom0's, but until this
happens, don't give the impression of this feature being useable elsewhere.
Signed-off-by:
Hi all,
Next week I'll be giving a talk about VM-to-VM communication mechanisms
at Embedded Linux Conf in Seattle.
One of the techniques I'll discuss, also the simplest, is shared memory
and interrupts. Although there is no binding to share memory between
dom0less VMs yet, it is already possible
flight 165130 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
Hi Andrew,
On Tue, 21 Sep 2021, 00:41 Andrew Cooper, wrote:
> The mapping interface can only be used by x86 PV guests.
>
Tracebuffer works on Arm... The support was added a couple of years ago
using the foreign mapping interface.
> This can and should be fixed by changing to an
flight 165129 qemu-mainline real [real]
flight 165132 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165129/
http://logs.test-lab.xenproject.org/osstest/logs/165132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Sun, 19 Sep 2021, Julien Grall wrote:
> On 18/09/2021 03:37, Stefano Stabellini wrote:
> > On Fri, 17 Sep 2021, Stefano Stabellini wrote:
> > > On Fri, 17 Sep 2021, Oleksandr wrote:
> > > > > > +
> > > > > > + dt_dprintk("Find unallocated memory for extended regions\n");
> > > > > > +
> > >
On Sun, 19 Sep 2021, Oleksandr wrote:
> > On 18/09/2021 03:37, Stefano Stabellini wrote:
> > > On Fri, 17 Sep 2021, Stefano Stabellini wrote:
> > > > On Fri, 17 Sep 2021, Oleksandr wrote:
> > > > > > > +
> > > > > > > + dt_dprintk("Find unallocated memory for extended regions\n");
> > > > > > >
On Mon, 20 Sep 2021, Oleksandr Andrushchenko wrote:
> On 20.09.21 14:30, Juergen Gross wrote:
> > On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
> >> Hello, Stefano!
> >>
> >> On 18.09.21 00:45, Stefano Stabellini wrote:
> >>> Hi Oleksandr,
> >>>
> >>> Why do you want to enable pciback on ARM?
On Mon, Sep 20, 2021 at 02:04:21PM +0200, Juergen Gross wrote:
> Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
> reservations") introduced early_reserve_memory() to do all needed
> initial memblock_reserve() calls in one function. Unfortunately the
> call of early_reserve_memory()
On 21.09.21 01:16, Stefano Stabellini wrote:
On Mon, 20 Sep 2021, Oleksandr Andrushchenko wrote:
On 20.09.21 14:30, Juergen Gross wrote:
On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
Hello, Stefano!
On 18.09.21 00:45, Stefano Stabellini wrote:
Hi Oleksandr,
Why do you want to enable
On Mon, Sep 20, 2021 at 02:04:21PM +0200, Juergen Gross wrote:
> Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
> reservations") introduced early_reserve_memory() to do all needed
> initial memblock_reserve() calls in one function. Unfortunately the
> call of early_reserve_memory()
On 21.09.21 08:20, Juergen Gross wrote:
> On 21.09.21 01:16, Stefano Stabellini wrote:
>> On Mon, 20 Sep 2021, Oleksandr Andrushchenko wrote:
>>> On 20.09.21 14:30, Juergen Gross wrote:
On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
> Hello, Stefano!
>
> On 18.09.21 00:45,
flight 165131 xen-unstable real [real]
flight 165135 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165131/
http://logs.test-lab.xenproject.org/osstest/logs/165135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi, Stefano!
On 21.09.21 02:16, Stefano Stabellini wrote:
> On Mon, 20 Sep 2021, Oleksandr Andrushchenko wrote:
>> On 20.09.21 14:30, Juergen Gross wrote:
>>> On 20.09.21 07:23, Oleksandr Andrushchenko wrote:
Hello, Stefano!
On 18.09.21 00:45, Stefano Stabellini wrote:
> Hi
On Mon, Sep 20, 2021 at 10:15 AM Jan Beulich wrote:
>
> On 20.09.2021 15:40, Tamas K Lengyel wrote:
> > During fork reset operation the parent domain doesn't need to be gathered
> > using
> > rcu_lock_live_remote_domain_by_id, the fork already has the parent pointer.
> >
> > Signed-off-by: Tamas
90 matches
Mail list logo
