flight 150041 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150041/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 149845
test-amd64-i386-xl-pvshim12
On 06.05.20 00:34, Stefano Stabellini wrote:
+ Boris, Jürgen
See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
related to the recent xen dma_ops changes. Possibly the same thing
reported by Peng here:
https://marc.info/?l=linux-kernel&m=158805976230485&w=2
An in-depth analy
On 05.05.20 22:57, Arnd Bergmann wrote:
On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote:
On 05.05.20 17:01, Arnd Bergmann wrote:
On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
On 05.05.20 16:15, Arnd Bergmann wrote:
I considered that as well, and don't really mind either way. I think i
On Tue, May 5, 2020 at 3:34 PM Stefano Stabellini
wrote:
>
> + Boris, Jürgen
>
> See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
> related to the recent xen dma_ops changes. Possibly the same thing
> reported by Peng here:
>
> https://marc.info/?l=linux-kernel&m=1588059762304
Adds a design document for DomB.
Signed-off-by: Christopher Clark
Signed-off by: Daniel P. Smith
---
This is a Request for Comments on this draft design document which
describes the motivation and design for the funded development of domB.
We invite discussion of this on this month’s Xen Commu
flight 150038 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 149649
Tests which did
flight 150039 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150039/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 149676
test-amd64-amd64-qemuu-nested-am
Normal World can share buffer with OP-TEE for two reasons:
1. Some client application wants to exchange data with TA
2. OP-TEE asks for shared buffer for internal needs
The second case was handle more strictly than necessary:
1. In RPC request OP-TEE asks for buffer
2. NW allocates buffer and pro
On 5/5/20 6:34 PM, Stefano Stabellini wrote:
>
>
> The crash happens here:
>
> if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
>range_straddles_page_boundary(phys, size)) &&
> TestClearPageXenRemapped(virt_to_page(vaddr)))
> xen_destroy_contigu
+ Boris, Jürgen
See the crash Roman is seeing booting dom0 on the Raspberry Pi. It is
related to the recent xen dma_ops changes. Possibly the same thing
reported by Peng here:
https://marc.info/?l=linux-kernel&m=158805976230485&w=2
An in-depth analysis below.
On Mon, 4 May 2020, Roman Shaposhn
flight 150049 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150049/
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 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote:
> On Thu, 30 Apr 2020 at 13:15, Daniel Kiper wrote:
> > Anyway, the advantage of this new protocol is that it uses UEFI API to
> > load and execute PE kernel and its modules. This means that it will be
> > architecture independent. Ho
On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote:
> On 05.05.20 17:01, Arnd Bergmann wrote:
> > On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> >> On 05.05.20 16:15, Arnd Bergmann wrote:
> >
> > I considered that as well, and don't really mind either way. I think it does
> > get a bit ugly wh
flight 150045 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150045/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate starved n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts
flight 150037 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150037/
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
AMD Fam15h processors introduced the flush-by-asid feature, for more fine
grain flushing purposes.
Flushing everything including ASID 0 (i.e. Xen context) is an an unnecesserily
large hammer, and never necessary in the context of guest TLBs needing
invalidating.
When available, use TLB_CTRL_FLUSH
Rework the vmcbcleanbits_t definitons to use bool, drop 'fields' from the
namespace, position the comments in an unambiguous position, and include the
bit position.
In svm_vmexit_handler(), don't bother conditionally writing ~0 or 0 based on
hardware support. The field was entirely unused and ign
Hi Juergen,
On 30/04/2020 06:38, Juergen Gross wrote:
The XS_INTRODUCE command has two parameters: the mfn (or better: gfn)
of the domain's xenstore ring page and the event channel of the
domain for communicating with Xenstore.
The gfn is not really needed. It is stored in the per-domain struct
On 05.05.20 18:12, Boris Ostrovsky wrote:
On 5/5/20 12:02 PM, Jürgen Groß wrote:
On 05.05.20 17:01, Arnd Bergmann wrote:
On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
On 05.05.20 16:15, Arnd Bergmann wrote:
The __xenbus_map_ring() function has two large arrays, 'map' and
'unmap' on its
On 5/5/20 12:02 PM, Jürgen Groß wrote:
> On 05.05.20 17:01, Arnd Bergmann wrote:
>> On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
>>> On 05.05.20 16:15, Arnd Bergmann wrote:
The __xenbus_map_ring() function has two large arrays, 'map' and
'unmap' on its stack. When clang decides to
On 05.05.20 17:01, Arnd Bergmann wrote:
On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
On 05.05.20 16:15, Arnd Bergmann wrote:
The __xenbus_map_ring() function has two large arrays, 'map' and
'unmap' on its stack. When clang decides to inline it into its caller,
xenbus_map_ring_valloc_hvm()
On 05.05.20 17:15, Edwin Torok wrote:
On Tue, 2020-05-05 at 14:13 +0100, Jürgen Groß wrote:
On 05.05.20 15:01, Julien Grall wrote:
Hi Paul,
On 28/04/2020 16:06, Paul Durrant wrote:
From: Paul Durrant
... to specify a separate migration stream that will also be
suitable for
live update.
The
On 05.05.2020 17:05, Andrew Cooper wrote:
> On 05/05/2020 15:52, Jan Beulich wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>> unless you have verified the sender and know the content is safe.
>>
>> On 05.05.2020 16:28, Andrew Cooper wrote:
>>> @@ -753,8 +751,9
On Tue, 2020-05-05 at 14:13 +0100, Jürgen Groß wrote:
> On 05.05.20 15:01, Julien Grall wrote:
> > Hi Paul,
> >
> > On 28/04/2020 16:06, Paul Durrant wrote:
> > > From: Paul Durrant
> > >
> > > ... to specify a separate migration stream that will also be
> > > suitable for
> > > live update.
> >
On 05/05/2020 15:52, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 05.05.2020 16:28, Andrew Cooper wrote:
>> @@ -753,8 +751,9 @@ void load_system_tables(void)
>> _set_ts
On 05.05.2020 16:17, Hongyan Xia wrote:
> From: Hongyan Xia
>
> stack++ can go into the next page and unmap_domain_page() will unmap the
> wrong one, causing mapcache and memory corruption. Fix.
>
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> On 05.05.20 16:15, Arnd Bergmann wrote:
> > The __xenbus_map_ring() function has two large arrays, 'map' and
> > 'unmap' on its stack. When clang decides to inline it into its caller,
> > xenbus_map_ring_valloc_hvm(), the total stack usage exceed
On 05.05.2020 16:11, Roger Pau Monné wrote:
> On Tue, May 05, 2020 at 03:47:43PM +0200, Jan Beulich wrote:
>> On 05.05.2020 11:24, Roger Pau Monne wrote:
>>> Remove the conversion of _PAGE_GNTTAB to a boolean, since the and
>>> operation performed afterwards will already return false if the value
>
The aim of this patch is to make it easier to digest the output of the
gitlab jobs, as the current is IMO too long and that makes it hard to
spot what went wrong. So this patch does the following:
- Rename build.log into run.log.
- Split each build log into a logs folder, using the
build{-kcon
On 05.05.2020 16:01, Hongyan Xia wrote:
> On Tue, 2020-05-05 at 15:38 +0200, Jan Beulich wrote:
>> On 05.05.2020 13:06, Hongyan Xia wrote:
>>> @@ -358,7 +359,7 @@ static void show_guest_stack(struct vcpu *v,
>>> const struct cpu_user_regs *regs)
>>> if ( mask == PAGE_SIZE )
>>> {
>>>
On 05.05.2020 16:51, Ian Jackson wrote:
> Andrew Cooper writes ("Backports to 4.13"):
>> On the tools side of things, f50a4f6e244c aafae0e800e9 2a62c22715bf
>> d79cc6bc2bac 0729830cc425 are all bugs in CPUID and/or migration. "Fix
>> HVM_PARAM_PAE_ENABLED handling" is only for 4.13, whereas all th
On 05.05.2020 16:28, Andrew Cooper wrote:
> @@ -753,8 +751,9 @@ void load_system_tables(void)
> _set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>sizeof(*tss) - 1, SYS_DESC_tss_avail);
> if ( IS_ENABLED(CONFIG_PV32) )
> - _set_tssldt_desc(compat_
Andrew Cooper writes ("Backports to 4.13"):
> On the tools side of things, f50a4f6e244c aafae0e800e9 2a62c22715bf
> d79cc6bc2bac 0729830cc425 are all bugs in CPUID and/or migration. "Fix
> HVM_PARAM_PAE_ENABLED handling" is only for 4.13, whereas all the others
> are back to 4.7 (technically speak
On 02.05.2020 00:58, Andrew Cooper wrote:
> When executing an IRET-to-self, the shadow stack must agree with the regular
> stack. We can't manipulate SSP directly, so have to fake a shadow IRET frame
> by executing 3 CALLs, then editing the result to look correct.
>
> This is not a fastpath, is c
On Tue, May 05, 2020 at 03:28:10PM +0100, Andrew Cooper wrote:
> Clang 3.5 doesn't do enough dead-code-elimination to drop the compat_gdt
> reference, resulting in a linker failure:
>
> hidden symbol `per_cpu__compat_gdt' isn't defined
>
> Drop the local variable, and move evaluation of this_cp
On 05.05.20 16:15, Arnd Bergmann wrote:
The __xenbus_map_ring() function has two large arrays, 'map' and
'unmap' on its stack. When clang decides to inline it into its caller,
xenbus_map_ring_valloc_hvm(), the total stack usage exceeds the warning
limit for stack size on 32-bit architectures.
dr
Clang 3.5 doesn't do enough dead-code-elimination to drop the compat_gdt
reference, resulting in a linker failure:
hidden symbol `per_cpu__compat_gdt' isn't defined
Drop the local variable, and move evaluation of this_cpu(compat_gdt) to within
the guarded region.
Reported-by: Roger Pau Monné
> -Original Message-
> From: Jan Beulich
> Sent: 05 May 2020 09:15
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monne
> ; Paul Durrant
> Subject: [PATCH v8 06/12] x86/HVM: make hvmemul_blk() capable of handling r/o
> operations
>
> In preparation for
From: Hongyan Xia
stack++ can go into the next page and unmap_domain_page() will unmap the
wrong one, causing mapcache and memory corruption. Fix.
Signed-off-by: Hongyan Xia
---
Changed in v2:
- tweak how the unmap is handled.
- fix the bug in compat as well.
- remove part of the commit messag
The __xenbus_map_ring() function has two large arrays, 'map' and
'unmap' on its stack. When clang decides to inline it into its caller,
xenbus_map_ring_valloc_hvm(), the total stack usage exceeds the warning
limit for stack size on 32-bit architectures.
drivers/xen/xenbus/xenbus_client.c:592:12: e
On Tue, May 05, 2020 at 03:47:43PM +0200, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 05.05.2020 11:24, Roger Pau Monne wrote:
> > Clang 10 complains with:
> >
> > mm.c:1
Sander Eikelenboom writes ("xen-4.13 tools/xentop.c backport request"):
> If I'm not mistaken you do the tools backports.
>
> I just noticed that the problem that is fixed by commit:
> 4b5b431edd984b26f43b3efc7de465f3560a949e tools/xentop: Fix calculation of
> used memory
>
> is already present
On Tue, 2020-05-05 at 15:38 +0200, Jan Beulich wrote:
> On 05.05.2020 13:06, Hongyan Xia wrote:
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -300,6 +300,7 @@ static void show_guest_stack(struct vcpu *v,
> > const struct cpu_user_regs *regs)
> > int i;
> > unsigned
> -Original Message-
> From: Markus Armbruster
> Sent: 05 May 2020 11:19
> To: qemu-de...@nongnu.org
> Cc: Stefano Stabellini ; Anthony Perard
> ; Paul
> Durrant ; Gerd Hoffmann ;
> xen-devel@lists.xenproject.org
> Subject: [PATCH v2 02/10] xen: Fix and improve handling of device_add
>
flight 150024 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150024/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-arm64-xs
On 05.05.2020 13:35, Andrew Cooper wrote:
> The caller is already guarded by is_pv_32bit_vcpu().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 05.05.2020 13:42, Andrew Cooper wrote:
> Several of these in particular haven't been pruned since the logic was all
> part of arch/x86/traps.c
>
> Some adjustments to header files are required to avoid compile errors:
> * emulate.h needs xen/sched.h because gdt_ldt_desc_ptr() uses v->vcpu_id.
On 05.05.2020 11:24, Roger Pau Monne wrote:
> Clang 10 complains with:
>
> mm.c:1239:10: error: converting the result of '<<' to a boolean always
> evaluates to true
> [-Werror,-Wtautological-constant-compare]
> if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
> ^
>
On 05.05.2020 13:06, Hongyan Xia wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -300,6 +300,7 @@ static void show_guest_stack(struct vcpu *v, const struct
> cpu_user_regs *regs)
> int i;
> unsigned long *stack, addr;
> unsigned long mask = STACK_SIZE;
> +v
On Tue, May 05, 2020 at 12:35:37PM +0100, Andrew Cooper wrote:
> The caller is already guarded by is_pv_32bit_vcpu().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On 05.05.20 15:01, Julien Grall wrote:
Hi Paul,
On 28/04/2020 16:06, Paul Durrant wrote:
From: Paul Durrant
... to specify a separate migration stream that will also be suitable for
live update.
The original scope of the document was to support non-cooperative
migration
of guests [1] but, s
Hi Paul,
On 28/04/2020 16:06, Paul Durrant wrote:
From: Paul Durrant
... to specify a separate migration stream that will also be suitable for
live update.
The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has b
On 05.05.2020 10:15, Jan Beulich wrote:
> @@ -11542,6 +11611,12 @@ int x86_emul_blk(
> switch ( state->blk )
> {
> bool zf;
> +struct {
> +struct x87_env32 env;
> +struct {
> + uint8_t bytes[10];
> +} freg[8];
> +}
Several of these in particular haven't been pruned since the logic was all
part of arch/x86/traps.c
Some adjustments to header files are required to avoid compile errors:
* emulate.h needs xen/sched.h because gdt_ldt_desc_ptr() uses v->vcpu_id.
* mmconfig.h needs to forward declare acpi_table_he
The caller is already guarded by is_pv_32bit_vcpu().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index cf28
From: Hongyan Xia
stack++ can go into the next page and unmap_domain_page() will unmap the
wrong one, causing mapcache and memory corruption. Fix.
This is found with direct map removal. For now, the idle domain does not
have a mapcache and uses the direct map, so no errors will occur.
Signed-of
usbback_portid_add() leaks the error when qdev_device_add() fails.
Fix that. While there, use the error to improve the error message.
The qemu_opts_from_qdict() similarly leaks on failure. But any
failure there is a programming error. Pass &error_abort.
Fixes: 816ac92ef769f9ffc534e49a1bb6177bd
Hello,
Patches 1 and 3 are fixes in order to build Xen with Clang 10. Patch 2
is a fix for a configure bug I've found while attempting to fix Clang
10.
Thanks, Roger.
Roger Pau Monne (3):
x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean
configure: also add EXTRA_PREFIX to {CPP/LD}
Clang 10 complains with:
mm.c:1239:10: error: converting the result of '<<' to a boolean always
evaluates to true
[-Werror,-Wtautological-constant-compare]
if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
^
xen/include/asm/x86_64/page.h:161:25: note: expanded from ma
The path provided by EXTRA_PREFIX should be added to the search path
of the configure script, like it's done in Config.mk. Not doing so
makes the search path for configure differ from the search path used
by the build.
Signed-off-by: Roger Pau Monné
---
Please re-run autoconf.sh after applying.
-
Clang 10 complains with:
13: error: misleading indentation; statement is not part of the previous 'if'
[-Werror,-Wmisleading-indentation]
if ( ! yyg->yy_state_buf )
^
libxlu_disk_l.c:1259:9: note: previous statement is here
if ( ! yyg->yy_state_buf )
^
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
sg_table->nent
If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
recalculate_mi
While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.
Also introduce the SVM related constants at this occasion.
Signed-off-by: Jan Beulich
---
v6: Re-base.
v5: The CPUID field used is just 8 bits wide.
v4: Add GENERAL2_I
On 05.05.2020 10:17, Jan Beulich wrote:
> AMD's PM specifies that MPERF (and its r/o counterpart) reads are
> affected by the TSC ratio. Hence when processing such reads in software
> we too should scale the values. While we don't currently (yet) expose
> the underlying feature flags, besides us al
AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU i
Note that FPU selector handling as well as MXCSR mask saving for now
does not honor differences between host and guest visible featuresets.
While for Intel operation of the insns with CR4.OSFXSR=0 is
implementation dependent, use the easiest solution there: Simply don't
look at the bit in the firs
AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU i
While the Intel SDM claims that FRSTOR itself may raise #MF upon
completion, this was confirmed by Intel to be a doc error which will be
corrected in due course; behavior is like FLDENV, and like old hard copy
manuals describe it. Otherwise we'd have to emulate the insn by filling
st(N) in suitable
To avoid introducing another boolean into emulator state, the
rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
info (affecting structure layout, albeit not size) to x86_emul_blk().
Signed-off-by: Jan Beulich
---
TBD: The full 16-bit padding fields in the 32-bit structures
There's nothing to be done by the emulator, as we unconditionally abort
any XBEGIN.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -208,6 +208,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-vnni", 0x0007, 0, CPUID
In preparation for handling e.g. FLDENV or {F,FX,X}RSTOR here as well.
Signed-off-by: Jan Beulich
---
v8: New (could be folded into "x86emul: support MOVDIR{I,64B} insns",
but would invalidate Paul's R-b there).
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1453,7 +14
Introduce a new blk() hook, paralleling the rmw() one in a certain way,
but being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.
Note that SDM revision 071 doesn't speci
... enabling its use by all guest kinds at the same time.
Signed-off-by: Jan Beulich
---
v7: Re-base.
v6: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -214,6 +214,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2,
Note that the ISA extensions document revision 038 doesn't specify
exception behavior for ModRM.mod == 0b11; assuming #UD here.
No tests are being added to the harness - this would be quite hard,
we can't just issue the insns against RAM. Their similarity with
MOVDIR64B should have the test case t
In a pure PV environment (the PV shim in particular) we don't really
need emulation of all these. To limit #ifdef-ary utilize some of the
CASE_*() macros we have, by providing variants expanding to
(effectively) nothing (really a label, which in turn requires passing
-Wno-unused-label to the compil
At least the RDPRU patch is still at least partly RFC. I'd
appreciate though if at least some of the series could go in rather
sooner than later. Note in particular that there's no strong
ordering throughout the entire series, i.e. certain later parts
could be arranged for to go in earlier. This is
77 matches
Mail list logo
