Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, June 7, 2022 3:58 PM
> To: Penny Zheng
> Cc: Wei Chen ; Andrew Cooper
> ; George Dunlap ;
> Julien Grall ; Stefano Stabellini ;
> Wei
> Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v6 9/9] xen: retrieve
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, June 7, 2022 5:13 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Wei Liu
> Subject: Re:
flight 170888 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714
On Wed, Jun 08, 2022 at 05:55:52PM -0700, Dongli Zhang wrote:
> /* Unique numbering for virtio devices. */
> @@ -241,6 +243,12 @@ static int virtio_dev_probe(struct device *_d)
> u64 device_features;
> u64 driver_features;
> u64 driver_features_legacy;
> + struct device
On Wed, Jun 08, 2022 at 05:55:53PM -0700, Dongli Zhang wrote:
> +#define slot_addr(start, idx)((start) + \
> + (((unsigned long)idx) << IO_TLB_SHIFT))
Please just convert it to an inline function.
On Wed, Jun 08, 2022 at 05:55:49PM -0700, Dongli Zhang wrote:
> @@ -109,19 +110,25 @@ int xen_swiotlb_fixup(void *buf, unsigned long nslabs,
> bool high)
> int rc;
> unsigned int order = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT);
> unsigned int i, dma_bits = order + PAGE_SHIFT;
This should be handled under the hood without the driver even knowing.
All this really needs to be hidden under the hood.
On Wed, Jun 08, 2022 at 05:55:47PM -0700, Dongli Zhang wrote:
> @@ -109,6 +109,7 @@ struct io_tlb_mem {
> } *slots;
> };
> extern struct io_tlb_mem io_tlb_default_mem;
> +extern struct io_tlb_mem io_tlb_high_mem;
Tis should not be exposed.
> +extern bool swiotlb_high_active(void);
And
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Wed, 8 Jun 2022 06:37:26 +0200 you wrote:
> Remove some unused macros and functions, make local functions static.
>
> Signed-off-by: Juergen Gross
> Acked-by: Wei Liu
> ---
>
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, June 7, 2022 5:20 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Wei Liu
>
flight 170884 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170884/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 170874 pass in 170884
Hi all,
Just a quick note to have another look at the spreadsheet before the
meeting tomorrow. I cleared the old rules we have already discussed
leaving only the ones to discuss next.
A few rules are similar to the already accepted Rule 5.1 with our agreed
40 characters limit for identifiers:
-
Hello,
I used to send out a patchset on 64-bit buffer and people thought it was
the same as Restricted DMA. However, the 64-bit buffer is still not supported.
https://lore.kernel.org/all/20210203233709.19819-1-dongli.zh...@oracle.com/
This RFC is to introduce the extra swiotlb buffer with
Currently, the virtio driver is not able to use 4+ GB memory when the
swiotlb is enforced, e.g., when amd sev is involved.
Fortunately, the SWIOTLB_ANY flag has been introduced since
commit 8ba2ed1be90f ("swiotlb: add a SWIOTLB_ANY flag to lift the low
memory restriction") to allocate swiotlb
Since the type of swiotlb slot index is a signed integer, the
"((idx) << IO_TLB_SHIFT)" will returns incorrect value. As a result, the
slot_addr() returns a value which is smaller than the expected one.
E.g., the 'tlb_addr' generated in swiotlb_tbl_map_single() may return a
value smaller than the
While for most of times the swiotlb-xen relies on the generic swiotlb api
to initialize and use swiotlb, this patch is to support highmem swiotlb
for swiotlb-xen specific code.
E.g., the xen_swiotlb_fixup() may request the hypervisor to provide
64-bit memory pages as swiotlb buffer.
Cc: Konrad
This patch is to implement the extra 'io_tlb_high_mem'. In the future, the
device drivers may choose to use either 'io_tlb_default_mem' or
'io_tlb_high_mem' as dev->dma_io_tlb_mem.
The highmem buffer is regarded as active if
(high_nslabs && io_tlb_high_mem.nslabs) returns true.
Cc: Konrad Wilk
The interface re-configures dev->dma_io_tlb_mem conditionally, if the
'io_tlb_high_mem' is active.
Cc: Konrad Wilk
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
include/linux/swiotlb.h | 6 ++
kernel/dma/swiotlb.c| 10 ++
2 files changed, 16 insertions(+)
diff --git
Add new argument 'high' to remap function, so that it will be able to
remap the swiotlb buffer based on whether the swiotlb is 32-bit or
64-bit.
Currently the only remap function is xen_swiotlb_fixup().
Cc: Konrad Wilk
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
When the swiotlb is enforced (e.g., when amd sev is involved), the virito
driver will not be able to use 4+ GB memory. Therefore, the virtio driver
uses 'io_tlb_high_mem' as swiotlb.
Cc: Konrad Wilk
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
drivers/virtio/virtio.c | 8
1 file
On Wed, 8 Jun 2022, Julien Grall wrote:
> On 08/06/2022 02:08, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/include/asm/pmap.h
> > > b/xen/arch/arm/include/asm/pmap.h
> > > new file mode 100644
> > > index ..74398b4c4fe6
> > > --- /dev/null
> > > +++
flight 170889 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170889/
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
flight 170881 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170881/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
>
> Current arch_cpu_idle() is called with IRQs disabled, but will return
> with IRQs enabled.
>
> However, the very first thing the generic code does after calling
> arch_cpu_idle() is raw_local_irq_disable(). This means that
> architectures
On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
>
> arch_cpu_idle() is a very simple idle interface and exposes only a
> single idle state and is expected to not require RCU and not do any
> tracing/instrumentation.
>
> As such, omap_sram_idle() is not a valid implementation. Replace it
>
flight 170877 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170877/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 7 xen-install fail in 170852 pass in 170877
On Wed, Jun 8, 2022 at 5:48 PM Peter Zijlstra wrote:
>
> On Wed, Jun 08, 2022 at 05:01:05PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
> > >
> > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > Xeons") wrecked intel_idle in
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> Typical boot time setup; no need to suffer an indirect call for that.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Frederic Weisbecker
Reviewed-by: Rafael J. Wysocki
> ---
> arch/x86/kernel/process.c | 50
>
flight 170886 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170886/
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 04.06.22 00:52, Stefano Stabellini wrote:
Hello Stefano
Thank you for having a look and sorry for the late response.
On Tue, 17 May 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add ability to allocate unpopulated DMAable (contiguous) pages
suitable for grant mapping
flight 170880 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170880/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714
Hi Jan,
On 02/06/2022 09:43, Jan Beulich wrote:
c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. While subsequently further restricted for Arm,
extend this to 12 TiB on x86, putting
On Wed, Jun 08, 2022 at 05:01:05PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
> >
> > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > Xeons") wrecked intel_idle in two ways:
> >
> > - must not have tracing in idle functions
> > -
On Wed, Jun 08, 2022 at 04:27:57PM +0200, Peter Zijlstra wrote:
> @@ -254,11 +255,18 @@ void omap_sram_idle(void)
>*/
> if (save_state)
> omap34xx_save_context(omap3_arm_context);
> +
> + if (rcuidle)
> + cpuidle_rcu_enter();
> +
> if (save_state
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> Xeons") wrecked intel_idle in two ways:
>
> - must not have tracing in idle functions
> - must return with IRQs disabled
>
> Additionally, it added a branch for no good
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Notably: this converts all dt_init_idle_driver() and
__CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined.
Signed-off-by: Peter Zijlstra (Intel)
---
Idle code is very like entry code in that RCU isn't available. As
such, add a little validation.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/alpha/kernel/vmlinux.lds.S |1 -
arch/arc/kernel/vmlinux.lds.S|1 -
arch/arm/include/asm/vmlinux.lds.h |1 -
Doing RCU-idle outside the driver, only to then temporarily enable it
again, some *four* times, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/cpuidle44xx.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
---
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/acpi/processor_idle.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/acpi/processor_idle.c
+++
vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
leaves .noinstr.text section
vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt() leaves
.noinstr.text section
vmlinux.o: warning: objtool: xen_safe_halt+0xa: call to
HYPERVISOR_sched_op.constprop.0()
vmlinux.o: warning: objtool: mwait_idle+0x47: call to
mds_idle_clear_cpu_buffers() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xa2: call to
mds_idle_clear_cpu_buffers() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle+0x91: call
No callers left that have already disabled RCU.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/time/tick-broadcast-hrtimer.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
--- a/kernel/time/tick-broadcast-hrtimer.c
+++
CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
enabled.
XXX if s390 (the only other GENERIC_ENTRY user as of this writing)
isn't comfortable with this, we could switch to
HAVE_NOINSTR_VALIDATION which is x86_64 only atm.
Signed-off-by: Peter Zijlstra (Intel)
---
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/powerdomain.c | 10 +-
drivers/base/power/runtime.c | 24
2 files changed, 17 insertions(+), 17 deletions(-)
--- a/arch/arm/mach-omap2/powerdomain.c
+++
The perf_lopwr_cb() is called from the idle routines; there is no RCU
there, we must not enter tracing.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/events/amd/brs.c | 13 +
arch/x86/include/asm/perf_event.h |2 +-
2 files changed, 6 insertions(+), 9 deletions(-)
vmlinux.o: warning: objtool: io_idle+0xc: call to __inb.isra.0() leaves
.noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0xfe: call to num_online_cpus()
leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0x115: call to
acpi_idle_fallback_to_c1.isra.0()
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-mvebu-v7.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/cpuidle/cpuidle-mvebu-v7.c
+++
cpuidle_state::enter() methods should be IRQ invariant
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/poll_state.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
+++ b/drivers/cpuidle/poll_state.c
@@ -17,7 +17,7 @@ static int __cpuidle
Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
normal interrupts") this function is called in regular IRQ context.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm64/kernel/smp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/kernel/smp.c
All callers should still have RCU enabled.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/cpu_pm.c |9 -
1 file changed, 9 deletions(-)
--- a/kernel/cpu_pm.c
+++ b/kernel/cpu_pm.c
@@ -30,16 +30,9 @@ static int cpu_pm_notify(enum cpu_pm_eve
{
int ret;
- /*
-
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx/cpuidle-imx6sx.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
---
Current rcu_idle_exit() is terminally broken because it uses
local_irq_{save,restore}(), which are traced which uses RCU.
However, now that all the callers are sure to have IRQs disabled, we
can remove these calls.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Paul E. McKenney
---
vmlinux.o: warning: objtool: intel_idle_s2idle+0x6e: call to
__monitor.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_irq+0x8c: call to
__monitor.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle+0x73: call to
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-tegra.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
---
Hi All! (omg so many)
These here few patches mostly clear out the utter mess that is cpuidle vs
rcuidle.
At the end of the ride there's only 2 real RCU_NONIDLE() users left
arch/arm64/kernel/suspend.c:RCU_NONIDLE(__cpu_suspend_exit());
drivers/perf/arm_pmu.c:
The whole disable-RCU, enable-IRQS dance is very intricate since
changing IRQ state is traced, which depends on RCU.
Add two helpers for the cpuidle case that mirror the entry code.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx/cpuidle-imx6q.c|4 +--
arch_cpu_idle() is a very simple idle interface and exposes only a
single idle state and is expected to not require RCU and not do any
tracing/instrumentation.
As such, omap_sram_idle() is not a valid implementation. Replace it
with the simple (shallow) omap3_do_wfi() call. Leaving the more
The __cpuidle functions will become a noinstr class, as such they need
explicit annotations.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/poll_state.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
+++
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-psci.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
---
vmlinux.o: warning: objtool: __halt+0x2c: call to hcall_func.constprop.0()
leaves .noinstr.text section
vmlinux.o: warning: objtool: __halt+0x3f: call to __tdx_hypercall() leaves
.noinstr.text section
vmlinux.o: warning: objtool: __tdx_hypercall+0x66: call to
__tdx_hypercall_failed() leaves
The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
tracepoint"), was printk usage from the cpuidle path where RCU was
already disabled.
Per the patches earlier in this series, this is no longer the case.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/printk/printk.c |2 +-
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-riscv-sbi.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
---
Doing RCU-idle outside the driver, only to then teporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/cpuidle34xx.c | 16
1 file changed, 16 insertions(+)
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/clk/clk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -978,12 +978,12 @@ static void clk_core_disable(struct clk_
if
OMAP3 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.
All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.
Signed-off-by: Peter Zijlstra (Intel)
---
Make cpuidle_enter_state() consistent with the s2idle variant and
verify ->enter() always returns with interrupts disabled.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/cpuidle/cpuidle.c
+++
Typical boot time setup; no need to suffer an indirect call for that.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
---
arch/x86/kernel/process.c | 50 +-
1 file changed, 28 insertions(+), 22 deletions(-)
---
None of these functions should ever be ran with RCU disabled anymore.
Specifically, do_handle_IPI() is only called from handle_IPI() which
explicitly does irq_enter()/irq_exit() which ensures RCU is watching.
The problem with smp_cross_call() was, per commit 7c64cc0531fa ("arm: Use
_rcuidle for
Now that arch_cpu_idle() is expected to return with IRQs disabled,
avoid the useless STI/CLI dance.
Per the specs this is supposed to work, but nobody has yet relied up
this behaviour so broken implementations are possible.
Cc: Isaku Yamahata
Cc: kirill.shute...@linux.intel.com
Signed-off-by:
Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
Xeons") wrecked intel_idle in two ways:
- must not have tracing in idle functions
- must return with IRQs disabled
Additionally, it added a branch for no good reason.
Fixes: c227233ad64c ("intel_idle: enable interrupts before C1
vmlinux.o: warning: objtool: mwait_idle+0x5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xc5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool:
Current arch_cpu_idle() is called with IRQs disabled, but will return
with IRQs enabled.
However, the very first thing the generic code does after calling
arch_cpu_idle() is raw_local_irq_disable(). This means that
architectures that can idle with IRQs disabled end up doing a
pointless
flight 170876 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
test-armhf-armhf-xl-credit1 14 guest-start
flight 170885 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170885/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ff36b2550f94dc5fac838cf298ae5a23cfddf204
baseline version:
ovmf
flight 170883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170883/
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
flight 170874 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170874/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken in 170858
Tests
Hi,
On 30/05/2022 10:09, Bertrand Marquis wrote:
On 23 May 2022, at 10:13, Michal Orzel wrote:
Introduce a command line parameter "maxcpus" on Arm to allow adjusting
the number of CPUs to activate. Currently the limit is defined by the
config option CONFIG_NR_CPUS. Such parameter already
Hi Stefano,
On 08/06/2022 02:08, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/include/asm/pmap.h b/xen/arch/arm/include/asm/pmap.h
new file mode 100644
index ..74398b4c4fe6
--- /dev/null
+++ b/xen/arch/arm/include/asm/pmap.h
@@ -0,0 +1,32 @@
+#ifndef __ASM_PMAP_H__
+#define
Hi Henry,
On 24/05/2022 02:53, Henry Wang wrote:
-Original Message-
From: Julien Grall
Subject: Re: [PATCH v3 2/2] xen/common: Use enhanced
ASSERT_ALLOC_CONTEXT in xmalloc()
Hi,
On 07/05/2022 03:54, Henry Wang wrote:
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
flight 170871 xen-4.16-testing real [real]
flight 170882 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170871/
http://logs.test-lab.xenproject.org/osstest/logs/170882/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, Jun 8, 2022 at 1:07 AM Stefano Stabellini
wrote:
>
> On Tue, 7 Jun 2022, Stefano Stabellini wrote:
> > On Tue, 7 Jun 2022, Jens Wiklander wrote:
> > > Hi,
> > >
> > > This patch sets add a FF-A [1] mediator modeled after the TEE mediator
> > > already present in Xen. The FF-A mediator
82 matches
Mail list logo
