On Mon, Apr 05, 2021 at 04:57:02PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> The function sh_audit_flags() is returning pointer to literal strings.
> They should not be modified, so the return is now const and this is
> propagated to the callers.
>
> Take the opportunity to fix the cod
On Mon, Apr 05, 2021 at 04:57:07PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> __bug() and __assert_failed() are not meant to modify the string
> parameters. So mark them as const.
>
> Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Monné
While looking at this I think we should al
On 02.04.2021 17:21, Julien Grall wrote:
> From: Julien Grall
>
> Currently perform_gunzip() can only be called once because the
> the internal state (e.g allocate) is not fully re-initialized.
>
> This works fine if you are only booting dom0. But this will break when
> booting multiple using th
On 02.04.2021 17:21, Julien Grall wrote:
> From: Julien Grall
>
> Hi all,
>
> The main goal of this series is to address the bug report [1]. It is not
> possible
...?
> While testing the series, I also noticed that it is not possible to
> re-use the same compressed kernel for multiple domains
On 05.04.2021 17:56, Julien Grall wrote:
> From: Julien Grall
>
> Hi all,
>
> By default, both Clang and GCC will happily compile C code where
> non-const char * point to literal strings. This means the following
> code will be accepted:
>
> char *str = "test";
>
> str[0] = 'a';
>
> L
On 05.04.2021 17:57, Julien Grall wrote:
> From: Julien Grall
>
> The string 'name' will never get modified by the function, so mark it
> as const.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
> --- a/xen/common/rangeset.c
> +++ b/xen/common/rangeset.c
> @@ -421,7 +421,7 @@ bool_
On 05.04.2021 17:57, Julien Grall wrote:
> From: Julien Grall
>
> Both name and opt_name are pointing to literal string. So mark both of
> the fields as const.
>
> Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
albeit ...
> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/priv
On 05.04.2021 17:57, Julien Grall wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -168,7 +168,7 @@ static int parse_guest_loglvl(const char *s);
> static char xenlog_val[LOGLVL_VAL_SZ];
> static char xenlog_guest_val[LOGLVL_VAL_SZ];
>
> -static char *lvl2opt[]
On 01.04.2021 21:43, Andrew Cooper wrote:
> On 01/04/2021 09:44, Roger Pau Monné wrote:
>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
>>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
And the obvious next question: is my EVE usecase esoteric enough that
I should just go a
flight 160761 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160761/
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
As of the conversion to safe_strcpy() years ago there has been no need
anymore to use snprintf() to prevent storing a not-nul-terminated string.
Signed-off-by: Jan Beulich
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -436,14 +436,7 @@ struct rangeset *rangeset_new(
BUG_ON(flag
On Tue, 30 Mar 2021, Lee Jones wrote:
> On Fri, 12 Mar 2021, Lee Jones wrote:
>
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Lee Jones (11):
> > block: rsxx: core: Remov
flight 160757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160757/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4ac02962017c77bf38b462f970c884c2dc7931cf
baseline version:
ovmf f95cdd316c3d56e8f76b5
On Fri, Mar 12, 2021 at 10:55:29AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/block/xen-blkfront.c:1960: warning: Function parameter or member
> 'dev' not described in 'blkfront_probe'
> drivers/block/xen-blkfront.c:1960: warning: Function parameter o
Roger Pau Monné writes ("Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH] fix
for_each_cpu() again for NR_CPUS=1)"):
> At this point, should be consider reverting the original fix from the
> 4.15 branch, so that we don't release something that's build broken
> with gcc 10?
Yes. I think so.
Rele
Roger Pau Monné writes ("Re: Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH]
fix for_each_cpu() again for NR_CPUS=1)"):
> On Thu, Apr 01, 2021 at 11:26:03AM +0200, Jan Beulich wrote:
> > Well, I didn't propose reverting (or taking this fix) because I think
> > build breakage is better than runtim
On 01.04.2021 16:01, Roger Pau Monné wrote:
> On Wed, Nov 25, 2020 at 09:51:33AM +0100, Jan Beulich wrote:
>> Except for the initial part of cstar_enter compat/entry.S is all dead
>> code in this case. Further, along the lines of the PV conditionals we
>> already have in entry.S, make code PV32-con
flight 160752 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken in 160709
build-armhf
This serie introduce doxygen in the sphinx html docs generation.
One benefit is to keep most of the documentation in the source
files of xen so that it's more maintainable, on the other hand
there are some limitation of doxygen that must be addressed
modifying the current codebase (for example doxy
Create a skeleton for the documentation about hypercalls
Signed-off-by: Luca Fancellu
---
.gitignore | 1 +
docs/Makefile | 4
docs/hypercall-interfaces/arm32.rst| 4
docs/hypercall-interfaces/arm64.rst| 32 +++
Modification to include/public/grant_table.h:
1) Change anonymous structure to be named structure,
because doxygen can't deal with them.
2) Add doxygen tags to:
- Create Grant tables section
- include variables in the generated documentation
3) Add .rst file for grant table for Arm64
Signed-
Unmask operation must be called with interrupt disabled,
on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
don't disable/enable interrupts, so use raw_* implementation
and change lock variable in struct irq_info from spinlock_t
to raw_spinlock_t
Cc: sta...@vger.kernel.org
Fixes: 25da4618af24
From: Hongyan Xia
This series rewrites all the remaining functions and finally makes the
switch from xenheap to domheap for Xen page tables, so that they no
longer need to rely on the direct map, which is a big step towards
removing the direct map.
---
Changed in v9:
- drop first 2 patches which
From: Wei Liu
Page tables allocated in that function should be mapped and unmapped
now.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
xen/arch/x86/mm.c | 60 ---
1 file changed, 36 insertions(+), 24 deletions(-)
di
From: Wei Liu
Rewrite those functions to use the new APIs. Modify its callers to unmap
the pointer returned. Since alloc_xen_pagetable_new() is almost never
useful unless accompanied by page clearing and a mapping, introduce a
helper alloc_map_clear_xen_pt() for this sequence.
Signed-off-by: Wei
From: Wei Liu
Page tables allocated in that function should be mapped and unmapped
now.
Note that pl2e now maybe mapped and unmapped in different iterations, so
we need to add clean-ups for that.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v7:
-
From: Wei Liu
We will soon map and unmap pages in paging_init(). Introduce pl2e so
that we can use l2_ro_mpt to point to the page table itself.
No functional change.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
Changed in v7:
- reword commit message.
---
xen/arch/x86/x86_64/mm.c | 16 ++
From: Wei Liu
Map and unmap pages instead of relying on the direct map.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v9:
- remove an unnecessary l3mfn variable.
Changed in v8:
- replace l3/2_ro_mpt_mfn with just mfn since their lifetimes do not
From: Wei Liu
While doing so, avoid repetitive mapping of l2_ro_mpt by keeping it
across loops, and only unmap and map it when crossing 1G boundaries.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v8:
- re-structure if condition around l2_ro_mpt.
-
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v8:
- remove redundant commit message.
- unmap l3src based on va instead of mfn.
- re-structure if condition around l3dst.
Changed in v7:
- hoist l3 variables out of the loop to avoid repe
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v7:
- add blank line after declaration.
- rename efi_l4_pgtable into efi_l4t.
- pass the mapped efi_l4t to copy_mapping() instead of map it again.
- use the alloc_map_clear_xen_pt() API.
-
From: Wei Liu
We will soon need to clean up page table mappings in the exit path.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v7:
- edit commit message.
- begin with rc = 0 and set it to -ENOMEM ahead of if().
---
xen/arch/x86/smpboot.c | 16 ++
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v7:
- change patch title
- remove initialiser of pl3e.
- combine the initialisation of pl3e into a single assignment.
- use the new alloc_map_clear() helper.
- use the normal map_domain_pag
From: Hongyan Xia
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
---
Changed in v8:
- const qualify pg in alloc_xen_pagetable_new().
---
xen/arch/x86/mm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/
From: Hongyan Xia
Two sets of old APIs, alloc/free_xen_pagetable() and lXe_to_lYe(), are
now dropped to avoid the dependency on direct map.
There are two special cases which still have not been re-written into
the new APIs, thus need special treatment:
rpt in smpboot.c cannot use ephemeral mapp
From: Wei Liu
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Acked-by: Jan Beulich
---
xen/arch/x86/mm.c| 44
xen/arch/x86/smpboot.c | 6 +++---
xen/arch/x86/x86_64/mm.c | 2 +-
xen/include/asm-x86/mm.h | 4 ++--
On 06.04.2021 12:36, Luca Fancellu wrote:
> Modification to include/public/grant_table.h:
>
> 1) Change anonymous structure to be named structure,
>because doxygen can't deal with them.
Especially in the form presented (adding further name space clutter
for consumers to fall over) I object to
This patch series is preparatory work to implement the PCI passthrough support
for the ARM architecture.
Rahul Singh (2):
xen/pci: Move PCI ATS code to common directory
xen/pci: Gate all MSI code in common code with CONFIG_HAS_PCI_MSI
xen/drivers/passthrough/Makefile| 1 +
xen/drive
PCI ATS code is common for all architecture, move code to common
directory to be usable for other architectures.
No functional change intended.
Signed-off-by: Rahul Singh
---
xen/drivers/passthrough/Makefile| 1 +
xen/drivers/passthrough/{x86 => }/ats.c | 2 +-
xen/drivers/passthrough/x
MSI support is not implemented for ARM architecture but it is enabled
for x86 architecture and referenced in common passthrough/pci.c code.
Therefore introducing the new flag to gate the MSI code for ARM in
common code to avoid compilation error when HAS_PCI is enabled for ARM.
Signed-off-by: Rah
On 06/04/2021 11:36, Luca Fancellu wrote:
> This serie introduce doxygen in the sphinx html docs generation.
> One benefit is to keep most of the documentation in the source
> files of xen so that it's more maintainable, on the other hand
> there are some limitation of doxygen that must be addresse
flight 160754 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi Jan,
On 06/04/2021 09:50, Jan Beulich wrote:
As of the conversion to safe_strcpy() years ago there has been no need
anymore to use snprintf() to prevent storing a not-nul-terminated string.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
--- a/xen/common/rangeset.c
+++ b/xen/common/
Hi Luca,
On 06/04/2021 11:51, Luca Fancellu wrote:
Unmask operation must be called with interrupt disabled,
on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
don't disable/enable interrupts, so use raw_* implementation
and change lock variable in struct irq_info from spinlock_t
to raw_spinl
On 06.04.2021 15:44, Julien Grall wrote:
> On 06/04/2021 09:50, Jan Beulich wrote:
>> As of the conversion to safe_strcpy() years ago there has been no need
>> anymore to use snprintf() to prevent storing a not-nul-terminated string.
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Julien Grall
T
This is a rework of the previously posted (now) 1st patch plus two
new ones.
1: don't build unused entry code when !PV32
2: x86: slim down hypercall handling when !PV32
3: x86: avoid building COMPAT code when !HVM && !PV32
Jan
At 16:57 +0100 on 05 Apr (1617641822), Julien Grall wrote:
> From: Julien Grall
>
> The function sh_audit_flags() is returning pointer to literal strings.
> They should not be modified, so the return is now const and this is
> propagated to the callers.
>
> Take the opportunity to fix the coding
Except for the initial part of cstar_enter compat/entry.S is all dead
code in this case. Further, along the lines of the PV conditionals we
already have in entry.S, make code PV32-conditional there too (to a
fair part because this code actually references compat/entry.S).
This has the side effect
In such a build various of the compat handlers aren't needed. Don't
reference them from the hypercall table, and compile out those which
aren't needed for HVM. Also compile out switch_compat(), which has no
purpose in such a build.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/Makef
It was probably a mistake to, over time, drop various CONFIG_COMPAT
conditionals from x86-specific code, as we now have a build
configuration again where we'd prefer this to be unset. Arrange for
CONFIG_COMPAT to actually be off in this case, dealing with fallout.
Signed-off-by: Jan Beulich
---
v
At 16:57 +0100 on 05 Apr (1617641829), Julien Grall wrote:
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to shore a pointer to them.
>
> Signed-off-by: Julien Grall
Acked-by: Tim Deegan
Thanks,
Tim.
Hi Jan,
On 06/04/2021 08:45, Jan Beulich wrote:
On 02.04.2021 17:21, Julien Grall wrote:
From: Julien Grall
Hi all,
The main goal of this series is to address the bug report [1]. It is not
possible
...?
Urgh, I forgot to add the rest of the sentence :/. I was meant to say
that it is not
On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote:
> MSI support is not implemented for ARM architecture but it is enabled
> for x86 architecture and referenced in common passthrough/pci.c code.
>
> Therefore introducing the new flag to gate the MSI code for ARM in
> common code to avoid
> On Apr 5, 2021, at 4:57 PM, Julien Grall wrote:
>
> From: Julien Grall
>
> literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> Signed-off-by: Julien Grall
Acked-by: George Dunlap
> On Apr 5, 2021, at 4:57 PM, Julien Grall wrote:
>
> From: Julien Grall
>
> Both name and opt_name are pointing to literal string. So mark both of
> the fields as const.
>
> Signed-off-by: Julien Grall
Acked-by: George Dunlap
Hi Roger,
On 06/04/2021 15:13, Roger Pau Monné wrote:
On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote:
MSI support is not implemented for ARM architecture but it is enabled
for x86 architecture and referenced in common passthrough/pci.c code.
Therefore introducing the new flag to g
On Tue, Apr 06, 2021 at 03:30:01PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 06/04/2021 15:13, Roger Pau Monné wrote:
> > On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote:
> > > MSI support is not implemented for ARM architecture but it is enabled
> > > for x86 architecture and refe
On 06/04/2021 15:59, Roger Pau Monné wrote:
On Tue, Apr 06, 2021 at 03:30:01PM +0100, Julien Grall wrote:
Hi Roger,
On 06/04/2021 15:13, Roger Pau Monné wrote:
On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote:
MSI support is not implemented for ARM architecture but it is enabled
On 06.04.2021 13:39, Rahul Singh wrote:
> PCI ATS code is common for all architecture, move code to common
> directory to be usable for other architectures.
>
> No functional change intended.
>
> Signed-off-by: Rahul Singh
Acked-by: Jan Beulich
On 3/12/21 3:55 AM, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Applied 2-11, 1 is already in the my tree.
--
Jens Axboe
On 06.04.2021 16:30, Julien Grall wrote:
> Hi Roger,
>
> On 06/04/2021 15:13, Roger Pau Monné wrote:
>> On Tue, Apr 06, 2021 at 12:39:11PM +0100, Rahul Singh wrote:
>>> MSI support is not implemented for ARM architecture but it is enabled
>>> for x86 architecture and referenced in common passthrou
On Tue, 06 Apr 2021, Jens Axboe wrote:
> On 3/12/21 3:55 AM, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
>
> Applied 2-11, 1 is already in the my tree.
Superstar
Hi,
Some time ago I've done an analysis what's the easiest way to improve VM
startup time, and one of the things that really stands out is block
script. VM with 4 disks can take up to 2s on waiting for block scripts.
A while ago I proposed a patch[1] that short-circuits the block script for
the si
On Tue, Apr 06, 2021 at 04:09:34PM +0100, Julien Grall wrote:
>
>
> On 06/04/2021 15:59, Roger Pau Monné wrote:
> > On Tue, Apr 06, 2021 at 03:30:01PM +0100, Julien Grall wrote:
> > > So I think we want to be able to compile out the code if not used. That
> > > said, I think providing stub would
George Dunlap writes ("[PATCH for-4.15 1/7] CHANGELOG.md: Mention
XEN_SCRIPT_DIR"):
> Signed-off-by: George Dunlap
Reviewed-by: Ian Jackson
On Tue, Apr 06, 2021 at 04:01:22PM +0200, Jan Beulich wrote:
> Except for the initial part of cstar_enter compat/entry.S is all dead
> code in this case. Further, along the lines of the PV conditionals we
> already have in entry.S, make code PV32-conditional there too (to a
> fair part because this
On Tue, Apr 06, 2021 at 04:01:41PM +0200, Jan Beulich wrote:
> In such a build various of the compat handlers aren't needed. Don't
> reference them from the hypercall table, and compile out those which
> aren't needed for HVM. Also compile out switch_compat(), which has no
> purpose in such a build
On Tue, Apr 06, 2021 at 04:02:08PM +0200, Jan Beulich wrote:
> It was probably a mistake to, over time, drop various CONFIG_COMPAT
> conditionals from x86-specific code, as we now have a build
> configuration again where we'd prefer this to be unset. Arrange for
> CONFIG_COMPAT to actually be off i
On 01/04/2021 15:37, Jan Beulich wrote:
> On 01.04.2021 16:31, Andrew Cooper wrote:
>> On 25/11/2020 08:51, Jan Beulich wrote:
>>> @@ -102,19 +102,21 @@ void __dummy__(void)
>>> BLANK();
>>> #endif
>>>
>>> -#ifdef CONFIG_PV
>>> +#ifdef CONFIG_PV32
>>> OFFSET(DOMAIN_is_32bit_pv, struct
On Tue, Apr 6, 2021 at 1:19 AM Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
> > On 01/04/2021 09:44, Roger Pau Monné wrote:
> >> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> >>> On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question:
On 06/04/2021 09:19, Jan Beulich wrote:
> On 01.04.2021 21:43, Andrew Cooper wrote:
>> On 01/04/2021 09:44, Roger Pau Monné wrote:
>>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
On 01.04.2021 03:06, Roman Shaposhnik wrote:
> And the obvious next question: is my EVE usecas
Hi Elliott,
Thanks for the input!
On 05/04/2021 18:01, Elliott Mitchell wrote:
On Mon, Apr 05, 2021 at 04:56:59PM +0100, Julien Grall wrote:
I am not aware of code trying to modify literal strings in Xen.
However, there is a frequent use of non-const char * to point to
literal strings. Given t
Hi Jan,
On 06/04/2021 08:57, Jan Beulich wrote:
On 05.04.2021 17:57, Julien Grall wrote:
From: Julien Grall
The string 'name' will never get modified by the function, so mark it
as const.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
Thanks!
--- a/xen/common/rangeset.c
+++ b
On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
wrote:
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote:
> On 01.04.2021 03:06, Roman Shapos
Hi Jan,
On 06/04/2021 09:07, Jan Beulich wrote:
On 05.04.2021 17:57, Julien Grall wrote:
From: Julien Grall
Both name and opt_name are pointing to literal string. So mark both of
the fields as const.
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
albeit ...
--- a/xen/common/sched
Hi Roger,
On 06/04/2021 08:24, Roger Pau Monné wrote:
On Mon, Apr 05, 2021 at 04:57:02PM +0100, Julien Grall wrote:
From: Julien Grall
The function sh_audit_flags() is returning pointer to literal strings.
They should not be modified, so the return is now const and this is
propagated to the c
Hi Jan,
On 06/04/2021 09:10, Jan Beulich wrote:
On 05.04.2021 17:57, Julien Grall wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -168,7 +168,7 @@ static int parse_guest_loglvl(const char *s);
static char xenlog_val[LOGLVL_VAL_SZ];
static char xenlog_guest_val[LO
flight 160758 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken in 160665
test-armhf-armhf-xl-cubietruck
Hi,
On 02/04/2021 16:21, Julien Grall wrote:
From: Julien Grall
Hi all,
The main goal of this series is to address the bug report [1]. It is not
possible
While testing the series, I also noticed that it is not possible to
re-use the same compressed kernel for multiple domains as the module
w
On 06/04/2021 19:03, Roman Shaposhnik wrote:
> On Tue, Apr 6, 2021 at 10:51 AM Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 06/04/2021 09:19, Jan Beulich wrote:
> > On 01.04.2021 21:43, Andrew Cooper wrote:
> >> On 01/04/2021 09:44, Roger Pau Monné wrote:
> >>> O
Hi Roger,
On 06/04/2021 08:29, Roger Pau Monné wrote:
On Mon, Apr 05, 2021 at 04:57:07PM +0100, Julien Grall wrote:
From: Julien Grall
__bug() and __assert_failed() are not meant to modify the string
parameters. So mark them as const.
Signed-off-by: Julien Grall
Reviewed-by: Roger Pau Mon
Hi,
On 05/04/2021 16:56, Julien Grall wrote:
Julien Grall (14):
xen: Constify the second parameter of rangeset_new()
xen/sched: Constify name and opt_name in struct scheduler
xen/x86: shadow: The return type of sh_audit_flags() should be const >
tools/firmware: hvmloader: Use const
On 02/04/2021 16:21, Julien Grall wrote:
From: Julien Grall
Currently, we are ignoring any error from perform_gunzip() and replacing
the compressed kernel with the "uncompressed" kernel.
If there is a gzip failure, then it means that the output buffer may
contain garbagge. So it can result
From: Julien Grall
Currently, we are ignoring any error from perform_gunzip() and replacing
the compressed kernel with the "uncompressed" kernel.
If there is a gzip failure, then it means that the output buffer may
contain garbagge. So it can result to various sort of behavior that may
be diffic
From: Julien Grall
Since commit 1aac966e24e9 "xen: support RAM at addresses 0 and 4096",
bits_to_zone() will never return 0 and it is expected that we have
minimum 2 zones.
Therefore the check in alloc_domheap_pages() is unnecessary and can
be removed. However, for sanity, it is replaced with an
From: Julien Grall
Currently, the heap_lock is held when clearing PGC_need_scrub in
alloc_heap_pages(). However, this is unnecessary because the only caller
(mark_page_offline()) that can concurrently modify the count_info is
using cmpxchg() in a loop.
Therefore, rework the code to avoid holding
Hi Jan,
On 01/04/2021 16:23, Jan Beulich wrote:
On 01.04.2021 16:56, Julien Grall wrote:
On 01/04/2021 11:19, Jan Beulich wrote:
--- a/xen/common/lib.c
+++ b/xen/lib/divmod.c
@@ -40,7 +40,6 @@
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
flight 160772 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160772/
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 1
On Tue, 6 Apr 2021, Andrew Cooper wrote:
> On 06/04/2021 11:36, Luca Fancellu wrote:
> > This serie introduce doxygen in the sphinx html docs generation.
> > One benefit is to keep most of the documentation in the source
> > files of xen so that it's more maintainable, on the other hand
> > there a
On Tue, 6 Apr 2021, Jan Beulich wrote:
> On 06.04.2021 12:36, Luca Fancellu wrote:
> > Modification to include/public/grant_table.h:
> >
> > 1) Change anonymous structure to be named structure,
> >because doxygen can't deal with them.
>
> Especially in the form presented (adding further name
On Fri, 2 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> Clang 11 will throw the following error:
>
> smmu.c:2284:18: error: cast to smaller integer type 'enum
> arm_smmu_arch_version' from 'const void *'
> [-Werror,-Wvoid-pointer-to-enum-cast]
> smmu->version = (enum arm_smmu_
On Mon, 5 Apr 2021, Julien Grall wrote:
> On 26/01/2021 22:58, Stefano Stabellini wrote:
> > Hi all,
>
> Hi Stefano,
>
> > This series introduces support for the generic SMMU bindings to
> > xen/drivers/passthrough/arm/smmu.c.
> >
> > The last version of the series was
> > https://marc.info/?l=x
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid guest-start/debian
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git:
flight 160774 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160774/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 160455
test-amd64-amd64-xl-qemut-win7-a
flight 160777 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160777/
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 1
flight 160763 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt-raw
flight 160767 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-
97 matches
Mail list logo
