flight 168766 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168766/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168760 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168760/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 168733
Tests which did not
flight 168762 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
ecf1bbe3227cc1c54d7374aa737e7e0e60ee0c29
Merge: 2058fdbe81 3515553bf6
Author: Peter Maydell
Date: Mon Mar 21 11:16:56 2022 +
Merge tag 'pull-ppc-20220321' of https://github.com/legoater/qemu into
staging
ppc-7.0 queue :
* ISA v3.1 vector instruction fixes
* Compilation fix regarding 'struct pt_regs
flight 168759 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168755 xen-unstable real [real]
flight 168761 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168755/
http://logs.test-lab.xenproject.org/osstest/logs/168761/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce domain-cpupool property of a xen,domain device tree node,
> that specifies the cpupool device tree handle of a xen,cpupool node
> that identifies a cpupool created at boot time where the guest will
> be assigned on creation.
>
> Add member to
On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have different cpu pools
Hi,
After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
this on resume from S3:
[ 88.082751] ACPI: PM: Low-level resume complete
[ 88.087933] ACPI: EC: EC started
[ 88.091464] ACPI: PM: Restoring platform NVS memory
[ 88.097166] xen_acpi_processor: Uploading Xen
On Mon, 21 Mar 2022, Julien Grall wrote:
> On 21/03/2022 19:47, Stefano Stabellini wrote:
> > On Sun, 20 Mar 2022, Julien Grall wrote:
> > > On 20/03/2022 01:46, Stefano Stabellini wrote:
> > > > On Fri, 18 Mar 2022, Stefano Stabellini wrote:
> > > > > Add a minimal ARM32 smoke test based on
On Mon, 21 Mar 2022, Julien Grall wrote:
> > This is the list of kernels that I tried and failed:
> >
> > - Debian Buster
> > - Debian Bullseye
> > - vanilla 4.9
> > - vanilla 4.10
>
> Does this mean you where using v4.{9,10}.0 rather than the stable branch?
>
> Note that AFAICT, 4.10 is not
During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being
On Mon, Mar 21, 2022, 12:41 PM Jan Beulich wrote:
> On 21.03.2022 17:26, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset right
Hi Stefano,
On 21/03/2022 19:47, Stefano Stabellini wrote:
On Sun, 20 Mar 2022, Julien Grall wrote:
On 20/03/2022 01:46, Stefano Stabellini wrote:
On Fri, 18 Mar 2022, Stefano Stabellini wrote:
Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu
Hi,
On 21/03/2022 19:29, Stefano Stabellini wrote:
On Sun, 20 Mar 2022, Julien Grall wrote:
On 20/03/2022 07:47, Julien Grall wrote:
On 20/03/2022 01:05, Stefano Stabellini wrote:
From: Stefano Stabellini
The first 32 bytes of zImage32 are NOPs, not useful just there for
compatibility. The
On Mon, 21 Mar 2022, Jan Beulich wrote:
> On 18.03.2022 22:50, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Jan Beulich wrote:
> >> On 11.03.2022 07:11, Penny Zheng wrote:
> >>> In case to own statically shared pages when owner domain is not
> >>> explicitly defined, this commits propose a
On Mon, 21 Mar 2022, Anthony PERARD wrote:
> On Fri, Mar 18, 2022 at 05:15:06PM -0700, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Anthony PERARD wrote:
> > > On Wed, Mar 16, 2022 at 06:38:53PM -0700, Stefano Stabellini wrote:
> > > > Also considering the recent arm32 xen breakage, which
On Sun, 20 Mar 2022, Julien Grall wrote:
> On 20/03/2022 01:46, Stefano Stabellini wrote:
> > On Fri, 18 Mar 2022, Stefano Stabellini wrote:
> > > Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> > > the test-artifacts qemu container. The minimal test simply boots Xen
> >
Hi Peng,
On 18/03/2022 05:24, Peng Fan wrote:
Subject: Re: [PATCH 3/3] xen/arm: Add i.MX8QM platform support
On 28/02/2022 01:07, Peng Fan (OSS) wrote:
+static const char * const imx8qm_dt_compat[] __initconst = {
+"fsl,imx8qm",
+NULL
+};
+
+PLATFORM_START(imx8qm, "i.MX 8")
+
Hi Peng,
On 18/03/2022 05:23, Peng Fan wrote:
Subject: Re: [PATCH 1/3] xen/arm: Add i.MX lpuart driver
On 28/02/2022 01:07, Peng Fan (OSS) wrote:
From: Peng Fan
+
+imx_lpuart_write(uart, UARTDATA, c); }
+
+static int imx_lpuart_getc(struct serial_port *port, char *pc) {
+struct
On Sun, 20 Mar 2022, Julien Grall wrote:
> On 20/03/2022 07:47, Julien Grall wrote:
> > On 20/03/2022 01:05, Stefano Stabellini wrote:
> > > From: Stefano Stabellini
> > >
> > > The first 32 bytes of zImage32 are NOPs, not useful just there for
> > > compatibility. The reason is that some
flight 168758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Bertrand,
On 21/03/2022 17:19, Bertrand Marquis wrote:
On 21 Mar 2022, at 17:36, Julien Grall wrote:
So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer
have more knowledge about that and
I can put a comment here.
On Arm, we are not yet supporting all the CPU
Hello,
This email is to request Xen community's feedback on our work on implementing
Xen’s driver domains using the unikernel virtual machine model (as opposed to
using general-purpose OSs like Linux) to reduce the attack surface, among other
benefits. The effort, called Kite, has implemented
Hi Julien,
> On 21 Mar 2022, at 17:36, Julien Grall wrote:
>
> Hi,
>
> On 21/03/2022 15:58, Luca Fancellu wrote:
>>> On 18 Mar 2022, at 16:12, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> I only skimmed through the series. I have one question below:
>>>
>>> On 18/03/2022 15:25, Luca
flight 168757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 21.03.2022 17:26, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This
Hi,
On 21/03/2022 15:58, Luca Fancellu wrote:
On 18 Mar 2022, at 16:12, Julien Grall wrote:
Hi Luca,
I only skimmed through the series. I have one question below:
On 18/03/2022 15:25, Luca Fancellu wrote:
+void __init btcpupools_allocate_pools(void)
+{
+unsigned int i;
+bool
During VM forking and resetting a failed vmentry has been observed due
to the guest non-register state going out-of-sync with the guest register
state. For example, a VM fork reset right after a STI instruction can trigger
the failed entry. This is due to the guest non-register state not being
On 21.03.2022 16:28, Tamas K Lengyel wrote:
> On Mon, Mar 21, 2022 at 10:58 AM Jan Beulich wrote:
>> On 21.03.2022 15:39, Tamas K Lengyel wrote:
>>> On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich wrote:
On 17.03.2022 16:57, Tamas K Lengyel wrote:
> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
> On 18 Mar 2022, at 16:12, Julien Grall wrote:
>
> Hi Luca,
>
> I only skimmed through the series. I have one question below:
>
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> +void __init btcpupools_allocate_pools(void)
>> +{
>> +unsigned int i;
>> +bool add_extra_cpupool = false;
> On 21 Mar 2022, at 09:10, Jan Beulich wrote:
>
> On 18.03.2022 16:25, Luca Fancellu wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -1,5 +1,6 @@
>> obj-$(CONFIG_ARGO) += argo.o
>> obj-y += bitmap.o
>> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
>
> By the
On Mon, Mar 21, 2022 at 10:58 AM Jan Beulich wrote:
>
> On 21.03.2022 15:39, Tamas K Lengyel wrote:
> > On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich wrote:
> >> On 17.03.2022 16:57, Tamas K Lengyel wrote:
> >>> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
> >>> #define XEN_X86_FPU_INITIALISED
flight 168754 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Mon, Mar 21, 2022 at 01:58:28PM +, Andrew Cooper wrote:
> By default, workflows run in all forks, but the Coverity token is specific to
> us, causing all other runs to fail.
>
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Albeit I have a suggestion to make this more useful I
flight 168750 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168750/
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 21.03.2022 15:39, Tamas K Lengyel wrote:
> On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich wrote:
>> On 17.03.2022 16:57, Tamas K Lengyel wrote:
>>> @@ -166,6 +167,11 @@ struct hvm_hw_cpu {
>>> #define XEN_X86_FPU_INITIALISED (1U<<_XEN_X86_FPU_INITIALISED)
>>> uint32_t flags;
>>>
On Mon, Mar 21, 2022 at 8:16 AM Jan Beulich wrote:
>
> On 17.03.2022 16:57, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset right
flight 168753 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 21.03.2022 15:12, Andrew Cooper wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1092,12 +1092,17 @@ static void setup_APIC_timer(void)
> local_irq_restore(flags);
> }
>
> +#define DEADLINE_MODEL_FUNCT(m, fn) \
> +{ .vendor = X86_VENDOR_INTEL, .family = 6, .model
On 21/03/2022 07:53, Juergen Gross wrote:
> The hypercall handler hvm_physdev_op() is missing a cf_check attribute.
>
> Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
> Signed-off-by: Juergen Gross
Sadly, cf_check typechecking doesn't work through casts. Introduce an ad-hoc
typecheck and fix *_readline_rev() checks to be cf_check.
This is a latent bug. The affected models don't have CET-IBT, so won't
actually explode from lacking endbr64 instructions.
Reported-by: Jan Beulich
flight 168752 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
By default, workflows run in all forks, but the Coverity token is specific to
us, causing all other runs to fail.
Signed-off-by: Andrew Cooper
---
CC: Roger Pau Monné
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
---
.github/workflows/coverity.yml |
On Mon, Mar 21, 2022 at 01:02:30PM +, Andrew Cooper wrote:
> On 21/03/2022 09:54, Roger Pau Monné wrote:
>
> Ping?
>
> On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:
>
>
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
>
> Note than when
flight 168751 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Jan,
On 21/03/2022 11:46, Jan Beulich wrote:
The initial three entries in .got.plt are "static", i.e. present
independent of actual entries allocation of which is triggered by
respective relocations. When no real entries are needed, halfway recent
ld discards the "static" portion of the
On 21/03/2022 09:54, Roger Pau Monné wrote:
Ping?
On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:
Introduce CodeQL support for Xen and analyze the C, Python and Go
files.
Note than when analyzing Python or Go we avoid building the hypervisor
and only build the tools.
On Thu, 17 Mar 2022 15:09:30 -0700, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
>
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"
>
>
Applied, thanks!
[1/1] xen/blkfront: fix comment
On Thu, 17 Mar 2022 23:46:46 +, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
>
> Cleans up clang scan build warning:
>
On 21.03.2022 12:57, Roger Pau Monné wrote:
> On Mon, Mar 21, 2022 at 12:46:54PM +0100, Jan Beulich wrote:
>> The initial three entries in .got.plt are "static", i.e. present
>> independent of actual entries allocation of which is triggered by
>> respective relocations. When no real entries are
On 17.03.2022 16:57, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This
flight 168749 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Mon, Mar 21, 2022 at 12:47:27PM +0100, Jan Beulich wrote:
> Oldish SUSE compilers generate .comment.SUSE.OPTS sections. Just like we
> already discard such for xen.efi, fold them into .comment for xen-syms.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
> ---
> Just like for
On Mon, Mar 21, 2022 at 12:46:54PM +0100, Jan Beulich wrote:
> The initial three entries in .got.plt are "static", i.e. present
> independent of actual entries allocation of which is triggered by
> respective relocations. When no real entries are needed, halfway recent
> ld discards the "static"
Oldish SUSE compilers generate .comment.SUSE.OPTS sections. Just like we
already discard such for xen.efi, fold them into .comment for xen-syms.
Signed-off-by: Jan Beulich
---
Just like for .comment itself I also wouldn't mind discarding these also
for the non-EFI case.
---
The initial three entries in .got.plt are "static", i.e. present
independent of actual entries allocation of which is triggered by
respective relocations. When no real entries are needed, halfway recent
ld discards the "static" portion of the table as well, but older GNU ld
fails to do so.
Fixes:
flight 168748 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168737 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168737/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 168722
Hi Jan,
On 21.03.2022 11:23, Jan Beulich wrote:
> Note: please properly quote your replies. As you'll see what you said
> in reply to my remarks is not properly separated from my remarks, and
> hence hard to read.
>
Sorry about that. I had some issues with my e-mail client and had to use the
flight 168747 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Fri, Mar 18, 2022 at 05:15:06PM -0700, Stefano Stabellini wrote:
> On Fri, 18 Mar 2022, Anthony PERARD wrote:
> > On Wed, Mar 16, 2022 at 06:38:53PM -0700, Stefano Stabellini wrote:
> > > Also considering the recent arm32 xen breakage, which could have been
> > > caught by gitlab-ci before
flight 168746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 21.03.22 11:05, Roger Pau Monné wrote:
On Thu, Mar 17, 2022 at 03:09:30PM -0700, Dongli Zhang wrote:
The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
copy the written data to persistent page.
".need_copy = rq_data_dir(req) && info->feature_persistent,"
I would also
On Fri, Mar 11, 2022 at 09:33:15AM +0100, Roger Pau Monné wrote:
> On Thu, Mar 10, 2022 at 06:01:48PM +, Andrew Cooper wrote:
> > On 08/03/2022 14:52, Roger Pau Monne wrote:
> > > On Tue, Mar 08, 2022 at 02:38:47PM +, Andrew Cooper wrote:
> > >> On 02/03/2022 14:27, Roger Pau Monne wrote:
Note: please properly quote your replies. As you'll see what you said
in reply to my remarks is not properly separated from my remarks, and
hence hard to read.
On 21.03.2022 11:14, Michal Orzel wrote:
> On 21.03.2022 09:21, Michal Orzel wrote:
>> --- /dev/null
>> +++ b/xen/include/xen/xen_lds.h
Hi Andrew,
On 16/03/2022 18:58, Andrew Cooper wrote:
diff --git a/xen/common/event_fifo.c b/xen/common/event_fifo.c
index ed4d3beb10f3..6c74ccebebb7 100644
--- a/xen/common/event_fifo.c
+++ b/xen/common/event_fifo.c
@@ -165,7 +165,7 @@ static void cf_check evtchn_fifo_set_pending(
Hi Jan,
On 21.03.2022 09:21, Michal Orzel wrote:
> Both x86 and arm linker scripts share quite a lot of common content.
> It is difficult to keep syncing them up, thus introduce a new header
> in include/xen called xen_lds.h to store the internals mutual to all
> the linker scripts.
>
>
On Thu, Mar 17, 2022 at 03:09:30PM -0700, Dongli Zhang wrote:
> The 'need_copy' is set when rq_data_dir(req) returns WRITE, in order to
> copy the written data to persistent page.
>
> ".need_copy = rq_data_dir(req) && info->feature_persistent,"
I would also add:
Fixes: c004a6fe0c40
On Thu, Mar 17, 2022 at 11:46:46PM +, Colin Ian King wrote:
> Variable i is being assigned a value that is never read, it is being
> re-assigned later in a for-loop. The assignment is redundant and can
> be removed.
>
> Cleans up clang scan build warning:
>
On 16/03/2022 18:38, Raphael Ning wrote:
Currently, evtchn_fifo_set_pending() will mark the event as PENDING even
if it fails to lock the FIFO event queue(s), or if the guest has not
initialized the FIFO control block for the target vCPU. A well-behaved
guest should never trigger either of these
Ping?
On Mon, Mar 07, 2022 at 05:45:52PM +0100, Roger Pau Monne wrote:
> Introduce CodeQL support for Xen and analyze the C, Python and Go
> files.
>
> Note than when analyzing Python or Go we avoid building the hypervisor
> and only build the tools.
>
> Requested-by: Andrew Cooper
>
flight 168745 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 21.03.2022 09:21, Michal Orzel wrote:
> Header file xen_lds.h defines common macros to be used in arch specific
> linker scripts. Include this header and make use of its helpers.
>
> Making use of common helpers defined based on x86 linker script
> improves arm linker script with:
> -explicit
On 21.03.2022 09:21, Michal Orzel wrote:
> Both x86 and arm linker scripts share quite a lot of common content.
> It is difficult to keep syncing them up, thus introduce a new header
> in include/xen called xen_lds.h to store the internals mutual to all
> the linker scripts.
>
> Populate
On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_ARGO) += argo.o
> obj-y += bitmap.o
> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
By the looks of it you appear to want to specify boot_cpupools.init.o
On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1182,6 +1182,7 @@ unsigned int btcpupools_get_cpupool_id(unsigned int
> cpu);
>
> #ifdef CONFIG_HAS_DEVICE_TREE
> void btcpupools_dtb_parse(void);
> +int
On 21.03.2022 08:53, Juergen Gross wrote:
> The hypercall handler hvm_physdev_op() is missing a cf_check attribute.
>
> Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 18.03.2022 22:50, Stefano Stabellini wrote:
> On Fri, 18 Mar 2022, Jan Beulich wrote:
>> On 11.03.2022 07:11, Penny Zheng wrote:
>>> In case to own statically shared pages when owner domain is not
>>> explicitly defined, this commits propose a special domain DOMID_SHARED,
>>> and we assign it
flight 168741 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168741/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Header file xen_lds.h defines common macros to be used in arch specific
linker scripts. Include this header and make use of its helpers.
Making use of common helpers defined based on x86 linker script
improves arm linker script with:
-explicit list of debug sections that otherwise are seen as
Header file xen_lds.h defines common macros to be used in arch specific
linker scripts. Include this header and make use of its helpers.
Signed-off-by: Michal Orzel
---
xen/arch/x86/xen.lds.S | 86 --
1 file changed, 8 insertions(+), 78 deletions(-)
diff
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen_lds.h to store the internals mutual to all
the linker scripts.
Populate xen_lds.h with the first portion of the common sections.
Some
This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.
The first patch creates a
flight 168740 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168740/
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
The hypercall handler hvm_physdev_op() is missing a cf_check attribute.
Fixes: cdbe2b0a1aec ("x86: Enable CET Indirect Branch Tracking")
Signed-off-by: Juergen Gross
---
xen/arch/x86/hvm/hypercall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/hypercall.c
On 18.03.22 19:40, Julien Grall wrote:
Hi Juergen,
On 17/03/2022 11:19, Juergen Gross wrote:
On 17.03.22 12:07, Julien Grall wrote:
On 16/03/2022 16:10, Juergen Gross wrote:
Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel P. Smith # xsm parts
Acked-by: Jan Beulich
---
V4:
- new patch
---
xen/arch/x86/compat.c |
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:
89 matches
Mail list logo
