Hi Julien,
On 06/02/2024 19:49, Julien Grall wrote:
>
>
> Hi Ayan,
>
> On 31/01/2024 12:10, Ayan Kumar Halder wrote:
>> There can be situations when the registers cannot be emulated to their full
>> functionality. This can be due to the complexity involved. In such cases, one
>> can emulate
On 07.02.2024 02:08, Stefano Stabellini wrote:
> On Tue, 6 Feb 2024, Jan Beulich wrote:
>> On 26.01.2024 11:05, Federico Serafini wrote:
>>> @@ -208,7 +205,7 @@ do {
>>>\
>>> case 8:
On 07.02.2024 01:56, Stefano Stabellini wrote:
> On Tue, 6 Feb 2024, Jan Beulich wrote:
>> On 02.02.2024 16:16, Simone Ballarin wrote:
>>> Rule 13.1: Initializer lists shall not contain persistent side effects
>>>
>>> This patch moves expressions with side-effects into new variables before
>>> the
On 07.02.2024 01:51, Stefano Stabellini wrote:
> On Wed, 13 Dec 2023, Simone Ballarin wrote:
>> From: Maria Celeste Cesario
>>
>> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
>> headline states:
>> "The controlling expression of an if statement and the controlling
>>
flight 184611 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184611/
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 Thu, Feb 1, 2024 at 10:15 PM Jan Beulich wrote:
> On 01.02.2024 14:32, George Dunlap wrote:
> > On Thu, Jun 23, 2022 at 12:54 PM Jan Beulich wrote:
> >
> >> By using | instead of || or (in the negated form) && chances increase
> >> for the compiler to recognize that both predicates can
On Tue, Feb 6, 2024 at 6:08 PM Petr Beneš wrote:
>
> From: Petr Beneš
>
> This patch addresses a behavior discrepancy in the handling of altp2m views,
> where upon the creation and subsequent EPT violation, the page access
> permissions were incorrectly inherited from the hostp2m instead of
On Tue, 6 Feb 2024, Jan Beulich wrote:
> On 06.02.2024 14:22, Jan Beulich wrote:
> > On 26.01.2024 11:05, Federico Serafini wrote:> ---
> > a/xen/include/xen/compiler.h
> >> +++ b/xen/include/xen/compiler.h
> >> @@ -64,6 +64,13 @@
> >> # define fallthroughdo {} while (0) /* fallthrough
On Tue, 6 Feb 2024, Jan Beulich wrote:
> On 26.01.2024 11:05, Federico Serafini wrote:
> > @@ -208,7 +205,7 @@ do {
> >\
> > case 8:
> > \
> >
On Fri, 26 Jan 2024, Federico Serafini wrote:
> Update ECLAIR configuration to consider safe switch clauses ending
> with STATIC_ASSERT_UNREACHABLE().
>
> Update docs/misra/deviations.rst accordingly.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Fri, 2 Feb 2024, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Function and macro properties contained in ECLAIR/call_properties.ecl are of
> general interest: this patch moves these annotations in a generaric JSON file
> in docs. In this way, they can be exploited for other
On Tue, 6 Feb 2024, Jan Beulich wrote:
> On 02.02.2024 16:16, Simone Ballarin wrote:
> > Rule 13.1: Initializer lists shall not contain persistent side effects
> >
> > This patch moves expressions with side-effects into new variables before
> > the initializer lists.
> >
> > No functional
On Mon, 5 Feb 2024, Jan Beulich wrote:
> On 05.02.2024 16:36, Nicola Vetrini wrote:
> > On 2023-12-13 17:10, Simone Ballarin wrote:
> >> From: Maria Celeste Cesario
> >>
> >> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
> >> headline states:
> >> "The controlling expression
On Wed, 13 Dec 2023, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> The xen sources contain violations of MISRA C:2012 Rule 14.4 whose
> headline states:
> "The controlling expression of an if statement and the controlling
> expression of an iteration-statement shall have essentially
On Tue, 6 Feb 2024, Michal Orzel wrote:
> At the moment, all Yocto jobs run on Arm64 runners. To address CI
> capacity issues, move yocto-qemux86-64 job to x86. Reflect the change in
> the makefile generating Yocto docker files and fix CONTAINER name
> definition that incorrectly expects
flight 184604 xen-unstable real [real]
flight 184610 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184604/
http://logs.test-lab.xenproject.org/osstest/logs/184610/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
From: Petr Beneš
It's located in libxl_domain_build_info, not libxl_domain_create_info.
---
tools/include/libxl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/libxl.h b/tools/include/libxl.h
index 907aa0a330..14f69823e0 100644
--- a/tools/include/libxl.h
+++
flight 184609 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184609/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1d0b95f6457d225c5108302a9da74b4ed7aa5a38
baseline version:
ovmf
flight 184607 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184607/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 62b43ec8960372abed59c1e1d596c2b324340a07
baseline version:
ovmf
Juergen Gross, le mar. 06 févr. 2024 20:11:25 +0100, a ecrit:
> The early error exit in p9_stat() returns without zeroing the p9_stat
> buffer, resulting in free() being called with an uninitialized pointer.
>
> Fix that by calling free_stat() in p9_stat() in case of returning an
> error and
The early error exit in p9_stat() returns without zeroing the p9_stat
buffer, resulting in free() being called with an uninitialized pointer.
Fix that by calling free_stat() in p9_stat() in case of returning an
error and potentially having allocated strings.
Reported-by: Julien Grall
Fixes:
Hi Ayan,
On 31/01/2024 12:10, Ayan Kumar Halder wrote:
From: Michal Orzel
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an
flight 184601 linux-linus real [real]
flight 184608 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184601/
http://logs.test-lab.xenproject.org/osstest/logs/184608/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Ayan,
On 31/01/2024 12:10, Ayan Kumar Halder wrote:
There can be situations when the registers cannot be emulated to their full
functionality. This can be due to the complexity involved. In such cases, one
can emulate those registers as RAZ/WI for example. We call them as partial
emulation.
Jürgen Groß, le mar. 06 févr. 2024 16:37:17 +0100, a ecrit:
> On 06.02.24 16:26, Samuel Thibault wrote:
> > Juergen Gross, le mar. 06 févr. 2024 07:17:21 +0100, a ecrit:
> > > The early error exit in p9_stat() returns without zeroing the p9_stat
> > > buffer, resulting in free() being called with
On 2/6/24 11:03, Kees Cook wrote:
Without changing the structure size (since it is UAPI), add a proper
flexible array member, and reference it in the kernel so that it will
not be trip the array-bounds sanitizer[1].
Link: https://github.com/KSPP/linux/issues/113 [1]
Cc: Juergen Gross
Cc:
Without changing the structure size (since it is UAPI), add a proper
flexible array member, and reference it in the kernel so that it will
not be trip the array-bounds sanitizer[1].
Link: https://github.com/KSPP/linux/issues/113 [1]
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Oleksandr
Hello Andrew,
Thank you for the quick response. I have no local modifications to Xen,
precisely in order to test it as cleanly as possible.
As soon as possible, I'll try to use a more recent version. Regarding the stack
trace, I believe the series of function calls starts from:
Le jeu. 1 févr. 2024 à 13:30, Sébastien Chaumat a
écrit :
> I spotted the following warning for IRQ7 (along with IRQ6 and 10)
>>
>> [0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type
>> function for IRQ 7 (IR-IO-APIC)
>>
>> This comes from kernel/irq/manage.c
>>
>>
>> int
On 2/2/24 16:33, Stewart Hildebrand wrote:
> ---
> Changes in v13:
> - hold off adding Roger's R-b tag even though it was provided on v12.2
> - use a wrapper construct to ease readability of odd-looking ASSERTs
> - new placement of ASSERT in __pci_enable_msix(), __pci_enable_msi(),
>and
On 06.02.24 16:26, Samuel Thibault wrote:
Juergen Gross, le mar. 06 févr. 2024 07:17:21 +0100, a ecrit:
The early error exit in p9_stat() returns without zeroing the p9_stat
buffer, resulting in free() being called with an uninitialized pointer.
Fix that by doing the zeroing first.
This is
Juergen Gross, le mar. 06 févr. 2024 07:17:21 +0100, a ecrit:
> The early error exit in p9_stat() returns without zeroing the p9_stat
> buffer, resulting in free() being called with an uninitialized pointer.
>
> Fix that by doing the zeroing first.
This is not coherent with the usual
At the moment, all Yocto jobs run on Arm64 runners. To address CI
capacity issues, move yocto-qemux86-64 job to x86. Reflect the change in
the makefile generating Yocto docker files and fix CONTAINER name
definition that incorrectly expects YOCTO_HOST variable to be set for x86
container as well,
Add a command line option to xentop to be able to display dom0 first, on top of
the list.
This is unconditional, so sorting domains with the S option will also ignore
dom0.
Signed-off-by: Cyril Rébert (zithro)
---
Changes in v2:
- bug fix
- add documentation
---
docs/man/xentop.1.pod | 6
On 05 Feb 2024 18:27, Anthony PERARD wrote:
On Wed, Jan 31, 2024 at 06:51:34PM +0100, Cyril Rébert wrote:
Add a command line option to xentop to be able to display dom0 first, on top of
the list.
This is unconditional, so sorting domains with the S option will also ignore
dom0.
The feature is defined in the tertiary exec control, and is available starting
from Sapphire Rapids and Alder Lake CPUs.
When enabled, two extra VMCS fields are used: SPEC_CTRL mask and shadow. Bits
set in mask are not allowed to be toggled by the guest (either set or clear)
and the value in the
On 06/02/2024 12:14 pm, Giuseppe De Rosa wrote:
> Bug detailed description:
>
>
>
> While booting a Linux Debian 7 "Wheezy" VM, Xen crashes with a FATAL
> PAGE FAULT.
>
>
>
> Environment :
>
>
>
> HW: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (2 CPU, Xen
flight 184605 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184605/
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 06.02.24 14:08, Andrew Cooper wrote:
On 06/02/2024 12:43 pm, Juergen Gross wrote:
A Xenstore stubdom should never be stoppable.
Reject attempts to do so.
Signed-off-by: Juergen Gross
I don't think this is a clever idea. `xl destroy` is also the "please
clean up my system when it's in a
On 06.02.2024 14:22, Jan Beulich wrote:
> On 26.01.2024 11:05, Federico Serafini wrote:> ---
> a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -64,6 +64,13 @@
>> # define fallthroughdo {} while (0) /* fallthrough */
>> #endif
>>
>> +/*
>> + * Add the following
On 26.01.2024 11:05, Federico Serafini wrote:
> @@ -208,7 +205,7 @@ do {
> \
> case 8:\
> put_unsafe_asm(x, ptr, grd, retval, "q", "", "ir",
On 26.01.2024 11:05, Federico Serafini wrote:> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -64,6 +64,13 @@
> # define fallthroughdo {} while (0) /* fallthrough */
> #endif
>
> +/*
> + * Add the following macro to check that a program point is considered
>
On Tue, Feb 6, 2024 at 5:08 AM Petr Beneš wrote:
>
> From: Petr Beneš
>
> This patch addresses a behavior discrepancy in the handling of altp2m views,
> where upon the creation and subsequent EPT violation, the page access
> permissions were incorrectly inherited from the hostp2m instead of
On 02.02.2024 16:16, Simone Ballarin wrote:
> Rule 13.1: Initializer lists shall not contain persistent side effects
>
> This patch moves expressions with side-effects into new variables before
> the initializer lists.
>
> No functional changes.
>
> Signed-off-by: Simone Ballarin
To be
On 02.02.2024 16:16, Simone Ballarin wrote:
> Rule 13.1: Initializer lists shall not contain persistent side effects
>
> The assignment operation in:
>
> .irq = rc = uart->irq,
>
> is a persistent side effect in a struct initializer list.
>
> This patch assigns rc separately outside the
On 06/02/2024 12:43 pm, Juergen Gross wrote:
> A Xenstore stubdom should never be stoppable.
>
> Reject attempts to do so.
>
> Signed-off-by: Juergen Gross
I don't think this is a clever idea. `xl destroy` is also the "please
clean up my system when it's in a very dead state" command, and that
Bug detailed description:
While booting a Linux Debian 7 "Wheezy" VM, Xen crashes with a FATAL PAGE FAULT.
Environment :
HW: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (2 CPU, Xen in nested
virtualization upon QEMU/KVM), 4GB RAM
Xen: Xen 4.14.6
A Xenstore stubdom should never be stoppable.
Reject attempts to do so.
Signed-off-by: Juergen Gross
---
tools/libs/light/libxl_domain.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c
index
From: Oleksandr Tyshchenko
Allow administrators to control whether Xen grant mappings for
the virtio disk devices should be used. By default (when new
parameter is not specified), the existing behavior is retained
(we enable grants if backend-domid != 0).
Signed-off-by: Oleksandr Tyshchenko
On 06.02.24 12:27, Anthony PERARD wrote:
Hello Anthony
[snip]
diff --git a/docs/man/xl-disk-configuration.5.pod.in
b/docs/man/xl-disk-configuration.5.pod.in
index bc945cc517..3c035456d5 100644
--- a/docs/man/xl-disk-configuration.5.pod.in
+++
While in the vast majority of cases failure of the function will not
be followed by re-invocation with the same emulation context, a few
very specific insns - involving multiple independent writes, e.g. ENTER
and PUSHA - exist where this can happen. Since failure of the function
only signals to
On 02.02.2024 16:16, Simone Ballarin wrote:
> Rule 13.1: Initializer lists shall not contain persistent side effects
>
> Effects caused by debug/logging macros and functions (like ASSERT,
> __bad_atomic_size,
> LOG, etc ...) that crash execution or produce logs are not dangerous in
>
On Tue, Feb 6, 2024 at 12:51 PM Jan Beulich wrote:
>
> On 06.02.2024 12:46, Carlo Nonato wrote:
> > On Thu, Feb 1, 2024 at 2:51 PM Jan Beulich wrote:
> >> On 29.01.2024 18:18, Carlo Nonato wrote:
> >>> @@ -229,6 +230,30 @@ int __init dom0_set_llc_colors(struct domain *d)
> >>> return
flight 184603 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184603/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ae59b8ba4166384cbfa32a921aac289bcff2aef9
baseline version:
ovmf
On 06.02.2024 12:46, Carlo Nonato wrote:
> On Thu, Feb 1, 2024 at 2:51 PM Jan Beulich wrote:
>> On 29.01.2024 18:18, Carlo Nonato wrote:
>>> @@ -229,6 +230,30 @@ int __init dom0_set_llc_colors(struct domain *d)
>>> return domain_check_colors(d);
>>> }
>>>
>>> +int
On 01.02.2024 18:01, Roger Pau Monne wrote:
> Currently when a unity range overlaps with memory being used as RAM by the
> hypervisor the result would be that the IOMMU gets disabled. However that's
> not enough, as even with the IOMMU disabled the device will still access the
> affected RAM
Hi Jan,
On Thu, Feb 1, 2024 at 2:51 PM Jan Beulich wrote:
>
> On 29.01.2024 18:18, Carlo Nonato wrote:
> > @@ -858,6 +859,16 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> > u_domctl)
> > __HYPERVISOR_domctl, "h", u_domctl);
> > break;
> >
> > +case
On Thu, Feb 01, 2024 at 01:30:21PM -0500, Jason Andryuk wrote:
> same_vm is broken when the two main domains do not have targets. otvm
> and targetvm are both missing, which means they get set to -1 and then
> converted to empty strings:
>
> ++10697+ local targetvm=-1
> ++10697+ local otvm=-1
>
On 01.02.2024 18:01, Roger Pau Monne wrote:
> Use the newly introduced generic unity map checker.
>
> Also drop the message recommending the usage of iommu_inclusive_mapping: the
> ranges would end up being mapped anyway even if some of the checks above
> failed, regardless of whether
On 06/02/2024 9:24 am, Jan Beulich wrote:
> On 05.02.2024 20:23, Oleksii Kurochko wrote:
>> * [PATCH v13 00/35] x86: enable FRED for x86-64 [
>> https://lore.kernel.org/xen-devel/20231205105030.8698-1-xin3...@intel.com/
>> ]
> This is a kernel series. I don't expect FRED support is in scope for
On 01.02.2024 18:01, Roger Pau Monne wrote:
> IVMD and RMRR ranges are functionally equivalent, and as so could use the same
> validity checker.
May I suggest s/equivalent/similar/?
> Move the IVMD to x86 common IOMMU code and adjust the function to take a pair
> of [start, end) mfn parameters.
On 06.02.2024 11:08, Petr Beneš wrote:
> From: Petr Beneš
>
> This commit introduces the ability to configure the maximum number of altp2m
> and nestedp2m tables through boot-time parameters. Previously, the limits
> were
> hardcoded to a maximum of 10 for both. This change allows for greater
On 06/02/2024 10:08 am, Petr Beneš wrote:
> From: Petr Beneš
>
> This commit introduces the ability to configure the maximum number of altp2m
> and nestedp2m tables through boot-time parameters. Previously, the limits
> were
> hardcoded to a maximum of 10 for both. This change allows for
On Mon, Feb 05, 2024 at 04:52:16PM +, Oleksandr Tyshchenko wrote:
> On 05.02.24 17:10, Anthony PERARD wrote:
> > On Fri, Feb 02, 2024 at 12:49:03PM +0200, Oleksandr Tyshchenko wrote:
> >> +grant_usage=1,? { libxl_defbool_set(>disk->grant_usage,
> >> true); }
> >> +grant_usage=0,?
From: Petr Beneš
This commit introduces the ability to configure the maximum number of altp2m
and nestedp2m tables through boot-time parameters. Previously, the limits were
hardcoded to a maximum of 10 for both. This change allows for greater
flexibility in environments that require more or
From: Petr Beneš
This patch addresses a behavior discrepancy in the handling of altp2m views,
where upon the creation and subsequent EPT violation, the page access
permissions were incorrectly inherited from the hostp2m instead of respecting
the altp2m default_access.
Previously, when a new
On 01.02.2024 18:01, Roger Pau Monne wrote:
> The current code that parses the IVMD blocks is relaxed with regard to the
> restriction that such unity regions should always fall into memory ranges
> marked as reserved in the memory map.
>
> However the type checks for the IVMD addresses are
On 05.02.2024 11:49, Frediano Ziglio wrote:
> Use 32 bit versions in all cases, not only for registers till 8th.
> This reduces the encoding from (example with r14):
>
> 49 c7 c6 ff 7f 00 00mov$0x7fff,%r14
>
> to
>
> 41 be ff 7f 00 00 mov$0x7fff,%r14d
>
>
On 05.02.2024 11:48, Frediano Ziglio wrote:
> We just pushed a 8-bytes zero and exception constants are
> small so we can just write a single byte saving 3 bytes for
> instruction.
> With ENDBR64 this reduces the size of the entry point from 32 to 16
> bytes (due to alignment).
Oh, good - when
flight 184597 xen-unstable real [real]
flight 184602 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184597/
http://logs.test-lab.xenproject.org/osstest/logs/184602/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 05.02.2024 11:47, Frediano Ziglio wrote:
> __HYPERVISOR_arch_1 and __HYPERVISOR_paging_domctl_cont for x86
> have the same value but this function is handling
> "paging_domctl_cont" hypercall so using the latter mnemonic in
> the code is more clear.
>
> Signed-off-by: Frediano Ziglio
On 05.02.2024 11:45, Frediano Ziglio wrote:
> Make clean they are not changed in the functions.
s/clean/clear/ ?
> Signed-off-by: Frediano Ziglio
Reviewed-by: Jan Beulich
On 05.02.2024 16:14, Andrew Cooper wrote:
> @@ -263,7 +266,7 @@ int bitmap_find_free_region(unsigned long *bitmap,
> unsigned int bits, unsigned i
> unsigned int pages = 1 << order;
If we mean to keep this function (see my reply to the other patch),
shouldn't we also check "order" along
On 05.02.2024 17:02, Julien Grall wrote:
> On 05/02/2024 15:14, Andrew Cooper wrote:
>> -int bitmap_find_free_region(unsigned long *bitmap, int bits, int order)
>> +int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits,
>> unsigned int order)
>> {
>> unsigned long mask;
>> -
On 06.02.2024 10:28, Roger Pau Monné wrote:
> On Mon, Feb 05, 2024 at 02:37:44PM +0100, Jan Beulich wrote:
>> This is a prereq to enabling e.g. the MSRLIST feature.
>>
>> Note that the PROCBASED_CTLS3 MSR is different from other VMX feature
>> reporting MSRs, in that all 64 bits report allowed
On 05.02.2024 16:55, Julien Grall wrote:
> On 05/02/2024 15:14, Andrew Cooper wrote:
>> Use pragmas to able the warning in this file only. All supported versions of
>> Clang understand this, while older GCCs simply ignore it.
>>
>> bitmap_find_free_region() is the only function which isn't
On Mon, Feb 05, 2024 at 02:37:44PM +0100, Jan Beulich wrote:
> This is a prereq to enabling e.g. the MSRLIST feature.
>
> Note that the PROCBASED_CTLS3 MSR is different from other VMX feature
> reporting MSRs, in that all 64 bits report allowed 1-settings.
>
> vVMX code is left alone, though,
On 05.02.2024 20:23, Oleksii Kurochko wrote:
> Hello everyone,
>
> I would like to share with you a list for status tracking based on Xen ML:
>
> Arm:
> * [PATCH v5 00/13] Arm cache coloring [
> https://lore.kernel.org/xen-devel/20240102095138.17933-1-carlo.non...@minervasys.tech/
> ]
> *
On 06.02.2024 10:15, Jan Beulich wrote:
> On 05.02.2024 22:21, Julien Grall wrote:
>> The tag says '2/5' but I don't see a thread. Is the series meant to
>> contain more patches?
>>
>> Also, the title is not very specific about where the assignment is
>> removed. I have committed with the
On 05.02.2024 22:21, Julien Grall wrote:
> The tag says '2/5' but I don't see a thread. Is the series meant to
> contain more patches?
>
> Also, the title is not very specific about where the assignment is
> removed. I have committed with the following title:
>
> xen/evtchn: Remove useful
80 matches
Mail list logo
