flight 164777 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 164788 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164787 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164785 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164772 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164772/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 164757
Tests which did not succee
flight 164779 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164779/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 0bb720b3c486bd3de62b8c32282eb5fa192b87f3
baseline version:
xtf bc26bc260cbfec1c6de177
On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote:
> Each POWER cpu has its own has_work() implementation. Instead of
> overloading CPUClass on each PowerPCCPUClass init, register the
> generic ppc_cpu_has_work() handler, and have it call the POWER
> specific has_work().
I don
On Thu, Sep 02, 2021 at 06:15:33PM +0200, Philippe Mathieu-Daudé wrote:
> Restrict has_work() to TCG sysemu.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
> target/ppc/cpu_init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/target/ppc/c
On Thu, 2 Sep 2021, Julien Grall wrote:
> > > +kinfo->mem.nr_banks = ++gbank;
> > > +kinfo->unassigned_mem -= tot_size;
> > > +if ( kinfo->unassigned_mem )
> > > +{
> > > +printk(XENLOG_ERR
> > > + "Size of \"memory\" property doesn't match up with the
> > > su
flight 164783 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git
flight 164778 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
Hi Stefano,
On 02/09/2021 22:32, Stefano Stabellini wrote:
On Tue, 24 Aug 2021, Penny Zheng wrote:
This commit introduces allocate_static_memory to allocate static memory as
guest RAM for Domain on Static Allocation.
It uses acquire_domstatic_pages to acquire pre-configured static memory
for t
On Thu, 2 Sep 2021, Stefano Stabellini wrote:
> On Tue, 24 Aug 2021, Penny Zheng wrote:
> > This commit introduces allocate_static_memory to allocate static memory as
> > guest RAM for Domain on Static Allocation.
> >
> > It uses acquire_domstatic_pages to acquire pre-configured static memory
> >
On Tue, 24 Aug 2021, Penny Zheng wrote:
> Static Allocation refers to system or sub-system(domains) for which memory
> areas are pre-defined by configuration using physical address ranges.
> Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
> beginning, shall never go to h
On Tue, 24 Aug 2021, Penny Zheng wrote:
> This commit introduces allocate_static_memory to allocate static memory as
> guest RAM for Domain on Static Allocation.
>
> It uses acquire_domstatic_pages to acquire pre-configured static memory
> for this domain, and uses guest_physmap_add_pages to set u
On Tue, 24 Aug 2021, Penny Zheng wrote:
> Static Allocation refers to system or sub-system(domains) for which memory
> areas are pre-defined by configuration using physical address ranges.
> Those pre-defined memory, -- Static Memory, as parts of RAM reserved in the
> beginning, shall never go to h
On Tue, 24 Aug 2021, Penny Zheng wrote:
> This patch introduces static memory initialization, during system boot up.
>
> The new function init_staticmem_pages is responsible for static memory
> initialization.
>
> Helper free_staticmem_pages is the equivalent of free_heap_pages, to free
> nr_mfns
flight 164775 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164760 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164760/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
The pull request you sent on Thu, 2 Sep 2021 09:29:21 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.15-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9ae5fceb9a20154d74586fe17d1096b981b23e34
Thank you!
--
Deet-doot-dot, I
flight 164773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164764 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164764/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
flight 164757 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164757/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164725
test-armhf-armhf-libvirt 16 sav
Jan Beulich writes ("Re: [PATCH 04/12] libxenguest: avoid allocating unused
deferred-pages bitmap"):
> [stuff]
I have read this conversation several times and it is not clear to me
whether Andrew was saying Jan's patch is bad, or the existing code is
bad.
I'm hesitant to give an ack for an optim
Jan Beulich writes ("Re: [PATCH 03/12] libxenguest: short-circuit "all-dirty"
handling"):
> On 25.06.2021 19:02, Andrew Cooper wrote:
> > Single all-dirty runs are a debugging technique only. All production
> > cases are live, and you don't want to fail midway through because a
> > late, large, m
Juergen Gross writes ("Re: [PATCH v2 02/13] libxc: split xc_logdirty_control()
from xc_shadow_control()"):
> On 05.07.21 17:12, Jan Beulich wrote:
> >>> +long long xc_logdirty_control(xc_interface *xch,
> >>> + uint32_t domid,
> >>> + unsig
Jan Beulich writes ("Re: [PATCH v2 03/13] libxenguest: deal with log-dirty op
stats overflow"):
> And - just to make it very explicit - even if I went this route to
> address a controversial point, I'd still like to understand the
> reason for the original objection - if only for my own education.
Juergen Gross writes ("Re: [PATCH] tools: ROUNDUP() related adjustments"):
> On 10.08.21 12:03, Jan Beulich wrote:
> > For one xc_private.h needlessly repeats xen-tools/libs.h's definition.
> >
> > And then there are two suspicious uses (resulting from the inconsistency
> > with the respective 2nd
Juergen Gross writes ("Re: [PATCH v2] tests/xenstore: link in librt if
necessary"):
> On 17.08.21 16:18, Jan Beulich wrote:
> > Old enough glibc has clock_gettime() in librt.so, hence the library
> > needs to be specified to the linker. Newer glibc has the symbol
> > available in both libraries, s
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/m68k/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 66d22d11895..94b35cb4a50 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -31
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/nios2/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/nios2/cpu.c b/target/nios2/cpu.c
index 947bb09bc1e..f1f976bdad7 100644
--- a/target/nios2/cpu.c
+++ b/target/nios2/cpu.c
@
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/microblaze/cpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/target/microblaze/cpu.c b/target/microblaze/cpu.c
index 15db277925f..74fbb5d201a 100644
--- a/target/microblaze/cpu.
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/cris/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/cris/cpu.c b/target/cris/cpu.c
index c2e7483f5bd..d6e486746be 100644
--- a/target/cris/cpu.c
+++ b/target/cris/cpu.c
@@ -35
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/avr/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/avr/cpu.c b/target/avr/cpu.c
index e9fa54c9777..6267cc6d530 100644
--- a/target/avr/cpu.c
+++ b/target/avr/cpu.c
@@ -32,6 +3
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/hppa/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c
index e8edd189bfc..cf1f656218f 100644
--- a/target/hppa/cpu.c
+++ b/target/hppa/cpu.c
@@ -60
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/ppc/cpu_init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 6aad01d1d3a..e2e721c2b81 100644
--- a/target/ppc/cpu_init.c
+++ b/target/p
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/cpu.c | 6 --
target/i386/tcg/tcg-cpu.c | 8 +++-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 04f59043804..b7417d29f44 100644
--
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/openrisc/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/openrisc/cpu.c b/target/openrisc/cpu.c
index 27cb04152f9..6544b549f12 100644
--- a/target/openrisc/cpu.c
+++ b/target/o
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/mips/cpu.c b/target/mips/cpu.c
index 00e0c55d0e4..3639c03f8ea 100644
--- a/target/mips/cpu.c
+++ b/target/mips/cpu.c
@@ -12
has_work() is sysemu specific, and Hexagon target only provides
a linux-user implementation. Remove the unused hexagon_cpu_has_work().
Signed-off-by: Philippe Mathieu-Daudé
---
target/hexagon/cpu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/target/hexagon/cpu.c b/target/hexagon/cpu
Each POWER cpu has its own has_work() implementation. Instead of
overloading CPUClass on each PowerPCCPUClass init, register the
generic ppc_cpu_has_work() handler, and have it call the POWER
specific has_work().
Signed-off-by: Philippe Mathieu-Daudé
---
target/ppc/cpu-qom.h | 3 +++
target/pp
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/rx/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/rx/cpu.c b/target/rx/cpu.c
index 25a4aa2976d..0d0cf6f9028 100644
--- a/target/rx/cpu.c
+++ b/target/rx/cpu.c
@@ -41,11 +41,13
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/riscv/cpu.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 13575c14085..abb555a8bdb 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cp
The common ppc_cpu_has_work() handler already checks for cs->halted,
so we can simplify all callees.
Signed-off-by: Philippe Mathieu-Daudé
---
target/ppc/cpu_init.c | 294 --
1 file changed, 138 insertions(+), 156 deletions(-)
diff --git a/target/ppc/cpu_
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/arm/cpu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index ba0741b20e4..e11aa625a5f 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -73,
Restrict has_work() to TCG sysemu.
Signed-off-by: Philippe Mathieu-Daudé
---
target/alpha/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c
index 93e16a2ffb4..32cf5a2ea9f 100644
--- a/target/alpha/cpu.c
+++ b/target/alpha/cpu.c
@
Add TCG target-specific has_work() handler in TCGCPUOps,
and add tcg_cpu_has_work() as AccelOpsClass has_work()
implementation.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/tcg-cpu-ops.h | 4
accel/tcg/tcg-accel-ops.c | 12
2 files changed, 16 insertions(+)
d
Implement WHPX has_work() handler in AccelOpsClass and
remove it from cpu_thread_is_idle() since cpu_has_work()
is already called.
Signed-off-by: Philippe Mathieu-Daudé
---
softmmu/cpus.c| 4 +---
target/i386/whpx/whpx-accel-ops.c | 6 ++
2 files changed, 7 insertions(+),
Implement KVM has_work() handler in AccelOpsClass and
remove it from cpu_thread_is_idle() since cpu_has_work()
is already called.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/kvm/kvm-accel-ops.c | 6 ++
softmmu/cpus.c| 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
dif
Introduce an accelerator-specific has_work() handler.
Eventually call it from cpu_has_work().
Signed-off-by: Philippe Mathieu-Daudé
---
include/sysemu/accel-ops.h | 5 +
softmmu/cpus.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/include/sysemu/accel-ops.h b/include/sy
We want to make cpu_has_work() per-accelerator. Only declare its
prototype and move its definition to softmmu/cpus.c.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 8 +---
softmmu/cpus.c| 8
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/i
cpu_has_work() is only called from system emulation code.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/core/cpu.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
index bc864564cee..2bd563
Commit 372579427a5 ("tcg: enable thread-per-vCPU") added the following
comment describing EXCP_HALTED in qemu_tcg_cpu_thread_fn():
case EXCP_HALTED:
/* during start-up the vCPU is reset and the thread is
* kicked several times. If we don't ensure we go back
* to sl
Hi,
CPU has_work() is a per-accelerator handler. This series
- explicit the KVM / WHPX implementations
- moves TCG implementations in AccelOpsClass
- explicit missing implementations (returning 'false').
Since v2:
- Full rewrite, no more RFC.
Supersedes: <20210304222323.1954755-1-f4...@amsat.org
From: Tianyu Lan Sent: Thursday, September 2, 2021 6:36 AM
>
> On 9/2/2021 8:23 AM, Michael Kelley wrote:
> >> + } else {
> >> + pages_wraparound = kcalloc(page_cnt * 2 - 1,
> >> + sizeof(struct page *),
> >> + GFP_
From: Christoph Hellwig Sent: Thursday, September 2, 2021 1:00 AM
>
> On Tue, Aug 31, 2021 at 05:16:19PM +, Michael Kelley wrote:
> > As a quick overview, I think there are four places where the
> > shared_gpa_boundary must be applied to adjust the guest physical
> > address that is used. Ea
On Thu, 2 Sep 2021, Wei Chen wrote:
> Hi Stefano,
>
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: 2021年9月2日 0:22
> > To: Wei Chen
> > Cc: Stefano Stabellini ; xen-
> > de...@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
> >
> > Subject: RE: [XEN RFC PATCH 24/40]
flight 164739 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164739/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 8 xen-boot fail in 164687 pass in 164739
test-armhf-armhf-xl-credit2 8
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年9月2日 14:00
> To: Stefano Stabellini ; Wei Chen
>
> Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
>
> Subject: Re: [XEN RFC PATCH 24/40] xen/arm: introduce a helper to parse
> device tree NUMA distance m
On 9/2/2021 8:23 AM, Michael Kelley wrote:
+ } else {
+ pages_wraparound = kcalloc(page_cnt * 2 - 1,
+ sizeof(struct page *),
+ GFP_KERNEL);
+
+ pages_wraparound[0] = pages;
+
On 01/09/2021 10:38, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 06.08.2021 13:12, Julien Grall wrote:
On 29/07/2021 12:47, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 29.07.2021 13:20, Julien Grall wrote:
Hi Michal,
On 29/07/2021 11:42, Michal Orzel wrote:
According to ARMv8A ar
On 02.09.2021 14:15, Juergen Gross wrote:
> On 02.09.21 13:42, Jan Beulich wrote:
>> On 02.09.2021 10:30, Jan Beulich wrote:
>>> The code building PVH Dom0 made use of sequences of P2M changes
>>> which are disallowed as of XSA-378. First of all population of the
>>> first Mb of memory needs to be
On 02.09.21 13:42, Jan Beulich wrote:
On 02.09.2021 10:30, Jan Beulich wrote:
The code building PVH Dom0 made use of sequences of P2M changes
which are disallowed as of XSA-378. First of all population of the
first Mb of memory needs to be redone. Then, largely as a
workaround, checking introduc
On 02.09.2021 13:48, Julien Grall wrote:
> On 02/09/2021 07:45, Jan Beulich wrote:
>> On 01.09.2021 20:11, Julien Grall wrote:
>>> I looked at the original commit to find out the reason to use the
>>> console lock. AFAICT, this was to allow console_force_unlock() to work
>>> properly. But it is not
flight 164758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
Hi Jan,
On 02/09/2021 07:45, Jan Beulich wrote:
On 01.09.2021 20:11, Julien Grall wrote:
On 01/09/2021 14:39, Jan Beulich wrote:
back in 2016 Andrew added code to x86'es variant to avoid interleaving
of output. The same issue ought to exist on Arm.
Agree. I guess we got away so far because i
On 02.09.2021 10:30, Jan Beulich wrote:
> The code building PVH Dom0 made use of sequences of P2M changes
> which are disallowed as of XSA-378. First of all population of the
> first Mb of memory needs to be redone. Then, largely as a
> workaround, checking introduced by XSA-378 needs to be slightl
On 9/2/2021 3:59 PM, Christoph Hellwig wrote:
On Tue, Aug 31, 2021 at 05:16:19PM +, Michael Kelley wrote:
As a quick overview, I think there are four places where the
shared_gpa_boundary must be applied to adjust the guest physical
address that is used. Each requires mapping a correspond
(trimming Cc list)
On 24.08.2021 12:49, Anthony PERARD wrote:
> Anthony PERARD (51):
> build: introduce cpp_flags macro
> build: use if_changed on built_in.o
> build: use if_changed_rules with %.o:%.c targets
> build: factorise generation of the linker scripts
> x86/mm: avoid building mu
Hi,
> On 2 Sep 2021, at 09:59, Julien Grall wrote:
>
>
>
> On 02/09/2021 08:57, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>> If I understand it right, you want a per guest parameter to be able to allow
>> PMU accesses.
>> This would require:
>> - to save/restore MDCR on conte
On 24.08.2021 12:49, Anthony PERARD wrote:
> This allows Makefile.clean to recurse into livepatch without help.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 24.08.2021 12:49, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
albeit with a remark:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -133,6 +133,9 @@ endif
> # Always build obj-bin files as binary even if they come from C source.
> $(obj-bin-y): XEN_CFLAGS
On 29.08.2021 14:18, Demi Marie Obenour wrote:
> The EFI System Reference Table (ESRT) is necessary for fwupd to identify
To properly match the UEFI spec, both here and in the subject I suppose
you mean "Resource" instead of "Reference"?
> @@ -171,7 +172,7 @@ static void __init
> efi_arch_proces
On Wed, Sep 01, 2021 at 01:53:34PM +0100, Alex Bennée wrote:
>
> Stefan Hajnoczi writes:
>
> > [[PGP Signed Part:Undecided]]
> > On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote:
> >> > Could we consider the kernel internally converting IOREQ messages from
> >> > the Xen hyperv
flight 164731 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164731/
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-
On 02/09/2021 08:57, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
If I understand it right, you want a per guest parameter to be able to allow
PMU accesses.
This would require:
- to save/restore MDCR on context switch
- introduce a new config parameter for guests (might or might not ne
There's not really any register state associated with offline vCPU-s, so
avoid spamming the log with largely useless information while still
leaving an indication of the fact.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -241,6 +2
vcpu_show_registers() didn't do anything for HVM so far. Note though
that some extra hackery is needed for VMX - see the code comment.
Note further that the show_guest_stack() invocation is left alone here:
While strictly speaking guest_kernel_mode() should be predicated by a
PV / !HVM check, show
Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
minimally acceptable shadow memory pool, rather than what normally
would be used (also, for example, for PVH). Populate the pool before
triggering the tasklet, on a best effort basis (again like done for
PVH).
Signed-off-by: Jan
Assuming that the accounting for IOMMU page tables will also take care
of the P2M needs was wrong: dom0_paging_pages() can determine a far
higher value, high enough for the system to run out of memory while
setting up Dom0. Hence in the case of shared page tables the larger of
the two values needs
To become independent of the sequence of mapping operations, permit
"access" to accumulate for Dom0, noting that there's not going to be an
introspection agent for it which this might interfere with. While e.g.
ideally only ROM regions would get mapped with X set, getting there is
quite a bit of wo
One of the changes comprising the fixes for XSA-378 disallows replacing
MMIO mappings by code paths not intended for this purpose. At least in
the case of PVH Dom0 hitting an RMRR covered by an E820 ACPI region,
this is too strict. Generally short-circuit requests establishing the
same kind of mapp
The code building PVH Dom0 made use of sequences of P2M changes
which are disallowed as of XSA-378. First of all population of the
first Mb of memory needs to be redone. Then, largely as a
workaround, checking introduced by XSA-378 needs to be slightly
relaxed.
Note that with these adjustments I g
flight 164751 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 164674
build-amd64-xsm
On Tue, Aug 31, 2021 at 05:16:19PM +, Michael Kelley wrote:
> As a quick overview, I think there are four places where the
> shared_gpa_boundary must be applied to adjust the guest physical
> address that is used. Each requires mapping a corresponding
> virtual address range. Here are the fou
Hi Julien,
> On 1 Sep 2021, at 19:33, Julien Grall wrote:
>
> Hi Stefano,
>
> On 01/09/2021 18:54, Stefano Stabellini wrote:
>> On Wed, 1 Sep 2021, Julien Grall wrote:
>>> On 01/09/2021 14:10, Bertrand Marquis wrote:
> On 1 Sep 2021, at 13:55, Julien Grall wrote:
>
> Hi,
>
>>
On Tue, Aug 31, 2021 at 11:20:06PM +0800, Tianyu Lan wrote:
>> If so I suspect the best way to allocate them is by not using vmalloc
>> but just discontiguous pages, and then use kmap_local_pfn where the
>> PFN includes the share_gpa offset when actually copying from/to the
>> skbs.
>>
> When netvs
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.15-rc1-tag
xen: branch for v5.15-rc1
It contains the following changes:
- some small cleanups
- a fix for a bug when running as Xen PV guest which could result in
not all memory
flight 164745 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164745/
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
Hi Christopher,
Thank you for your feedback.
On Mon, Aug 30, 2021 at 12:53:00PM -0700, Christopher Clark wrote:
> [ resending message to ensure delivery to the CCd mailing lists
> post-subscription ]
>
> Apologies for being late to this thread, but I hope to be able to
> contribute to
> this dis
The initial if() was inverted, invalidating all output from this
function. Which in turn means the mirroring of P2M mappings into the
IOMMU didn't always work as intended: Mappings may have got updated when
there was no need to. There would not have been too few (un)mappings;
what saves us is that
On 01.09.2021 22:02, Andrew Cooper wrote:
> On 01/09/2021 17:06, Jan Beulich wrote:
>> The function may fail; it is not correct to indicate "success" in this
>> case up the call stack. Mark the function must-check to prove all
>> cases have been caught (and no new ones will get introduced).
>>
>> S
94 matches
Mail list logo
