On 05/03/2024 20:24, Julien Grall wrote:
>
>
> Hi Jan,
>
> The title is quite confusing. I would have expected the macro...
>
> On 05/03/2024 08:33, Jan Beulich wrote:
>> There's no use of them anymore except in the definitions of the non-
>> underscore-prefixed aliases. Rename the inline
In light of recent observations with how macros are handled by gas,
let's play by what we informally set for ourselves as a guideline: Use
commas to separate parameters/arguments.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@
On 05.03.2024 20:24, Julien Grall wrote:
> Hi Jan,
>
> The title is quite confusing. I would have expected the macro...
>
> On 05/03/2024 08:33, Jan Beulich wrote:
>> There's no use of them anymore except in the definitions of the non-
>> underscore-prefixed aliases. Rename the inline functions,
flight 184916 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184916/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e60529df58e43f4d1652f862c6652b61f21e0691
baseline version:
ovmf
From: Peng Hao
From: Peng Hao
Use kmap_local_page() instead of kmap_atomic() which has been
deprecated.
Signed-off-by: Peng Hao
---
drivers/block/xen-blkback/blkback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
flight 184910 xen-4.18-testing real [real]
flight 184915 xen-4.18-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184910/
http://logs.test-lab.xenproject.org/osstest/logs/184915/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184909 xen-4.17-testing real [real]
flight 184913 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184909/
http://logs.test-lab.xenproject.org/osstest/logs/184913/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Add the shutdown reasons to the paragraph of "xl list" concerning the
shutdown status.
I have copy/pasted the explanations from the source code :
- tools/xl/xl_info.c (L379)
- xen/include/public/sched.h (starting L158)
Suggested-by: Roger Pau Monné
Signed-off-by: Cyril Rébert / zithro
---
Hi Jan,
The title is quite confusing. I would have expected the macro...
On 05/03/2024 08:33, Jan Beulich wrote:
There's no use of them anymore except in the definitions of the non-
underscore-prefixed aliases. Rename the inline functions, adjust the
virt_to_maddr() #define-e, and purge the
From: Frédéric Pierret (fepitre)
When running in a stubdomain, the config space access via sysfs needs to
use BDF as seen inside stubdomain (connected via xen-pcifront), which is
different from the real BDF. For other purposes (hypercall parameters
etc), the real BDF needs to be used.
Get the
Introduce global xen_is_stubdomain variable when qemu is running inside
a stubdomain instead of dom0. This will be relevant for subsequent
patches, as few things like accessing PCI config space need to be done
differently.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- use sigend
On Tue, 2024-03-05 at 16:43 +0100, Jan Beulich wrote:
> On 05.03.2024 16:15, Oleksii wrote:
> > I agree that upon examining the current state of the code around
> > these
> > functions, it appears safe to provide stubs. However, the reason my
> > patch was rejected is that it may not be entirely
On Mon, 2024-03-04 at 09:10 +0100, Jan Beulich wrote:
> On 01.03.2024 18:21, Oleksii wrote:
> > * limit passing around of cpu_user_regs [
> > https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da9...@suse.com/
> > ]:
> > new patch series version was sent.
>
> This was committed
Hi Andrew,
On 3/5/24 6:21 AM, Andrew Cooper wrote:
> This is bad copy/paste from somewhere. Retain the second _erodata symbol,
> which follows the Build ID, and matches the other architectures.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
For the PPC part:
Acked-by: Shawn
On Tue, 2024-03-05 at 09:05 +0100, Jan Beulich wrote:
> On 26.02.2024 18:39, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/docs/misc/riscv/booting.txt
> > @@ -0,0 +1,8 @@
> > +System requirements
> > +===
> > +
> > +The following extensions are expected to be supported by a
FWIW, this is not tied to patch 1, so can go in independently. I
think it's a worthwhile improvement.
Thanks, Roger.
On Thu, Feb 29, 2024 at 10:55:29AM +0100, Roger Pau Monne wrote:
> The generated code between the debug and release builds can be quite
> different, as a note 2ce562b2a413 only
On Tue, 2024-03-05 at 09:17 +0100, Jan Beulich wrote:
> On 26.02.2024 18:39, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/mm.h
> > +++ b/xen/arch/riscv/include/asm/mm.h
> > @@ -3,11 +3,252 @@
> > #ifndef _ASM_RISCV_MM_H
> > #define _ASM_RISCV_MM_H
> >
> > +#include
> >
On 04.03.2024 17:36, Jan Beulich wrote:
> On 04.03.2024 16:39, Federico Serafini wrote:
>> On 04/03/24 15:17, Jan Beulich wrote:
>>> On 04.03.2024 14:31, Federico Serafini wrote:
On 01/03/24 09:06, Jan Beulich wrote:
> On 01.03.2024 00:28, Stefano Stabellini wrote:
>> On Wed, 14 Feb
On 2024-03-05 11:26, Jan Beulich wrote:
On 05.03.2024 11:21, Nicola Vetrini wrote:
On 2024-02-29 23:49, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Nicola Vetrini wrote:
On 2024-02-29 17:40, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/include/public/xen.h
+++
On Thu, Feb 22, 2024 at 05:16:09PM -0800, Stefano Stabellini wrote:
> On Tue, 20 Feb 2024, Roger Pau Monne wrote:
> > When running as PVH or HVM Linux will use holes in the memory map as scratch
> > space to map grants, foreign domain pages and possibly miscellaneous other
> > stuff. However the
On 05/03/2024 3:43 pm, Jan Beulich wrote:
> On 05.03.2024 16:15, Oleksii wrote:
>> I agree that upon examining the current state of the code around these
>> functions, it appears safe to provide stubs. However, the reason my
>> patch was rejected is that it may not be entirely safe, as Julien
>>
On 05.03.2024 16:15, Oleksii wrote:
> I agree that upon examining the current state of the code around these
> functions, it appears safe to provide stubs. However, the reason my
> patch was rejected is that it may not be entirely safe, as Julien
> pointed out that even with Arm, some functions
On 05.03.24 15:33, Jan Beulich wrote:
Neither pread() / pwrite() nor O_DIRECTORY are available from glibc
2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the
definition unconditionally shouldn't be a problem, seeing that various
other tools/ components do so, too.
Signed-off-by:
On Mon, 2024-03-04 at 17:50 +, Andrew Cooper wrote:
> On 04/03/2024 5:40 pm, Julien Grall wrote:
> > Hi Andrew,
> >
> > On 04/03/2024 17:07, Andrew Cooper wrote:
> > > On 04/03/2024 4:55 pm, Jan Beulich wrote:
> > > > On 04.03.2024 17:46, Julien Grall wrote:
> > > > > On 04/03/2024 16:41, Jan
Changes looks good to me.
Reviewed-by: Oleksii Kurochko
I'll update the RISC-V part correspondingly.
~ Oleksii
On Tue, 2024-03-05 at 09:33 +0100, Jan Beulich wrote:
> There's no use of them anymore except in the definitions of the non-
> underscore-prefixed aliases. Rename the inline
RISC-V changes look good to me.
Reviewed-by: Oleksii Kurochko
~ Oleksii
On Tue, 2024-03-05 at 12:21 +, Andrew Cooper wrote:
> This is bad copy/paste from somewhere. Retain the second _erodata
> symbol,
> which follows the Build ID, and matches the other architectures.
>
> No functional
Neither pread() / pwrite() nor O_DIRECTORY are available from glibc
2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the
definition unconditionally shouldn't be a problem, seeing that various
other tools/ components do so, too.
Signed-off-by: Jan Beulich
--- a/tools/9pfsd/Makefile
On 05.03.2024 13:11, Andrew Cooper wrote:
> --- a/xen/include/xen/virtual_region.h
> +++ b/xen/include/xen/virtual_region.h
> @@ -16,6 +16,9 @@ struct virtual_region
> const void *text_start;/* .text virtual address start. */
> const void *text_end; /*
Much like was recently done for setting entry vector, and along the
lines of what we already had in handle_exception_saved, avoid 32-bit
immediates where 8-bit ones do. Reduces .text.entry size by 16 bytes in
my non-CET reference build, while in my CET reference build section size
doesn't change
On Tue, Mar 05, 2024 at 01:02:37PM +, Andrew Cooper wrote:
> On 05/03/2024 12:11 pm, Andrew Cooper wrote:
> > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
> > index d2efe9e11492..f45812483b8e 100644
> > --- a/xen/common/virtual_region.c
> > +++
On Tue, Mar 05, 2024 at 12:11:20PM +, Andrew Cooper wrote:
> These are optional. .init doesn't distinguish types of data like this, and
> livepatches don't necesserily have any .rodata either.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
On Tue, Mar 05, 2024 at 12:11:19PM +, Andrew Cooper wrote:
> ... to text_{start,end}. We're about to introduce another start/end pair.
>
> As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice
> PAGE_ALIGN() ahead of duplicating the example.
>
> No functional change.
>
>
On 05/03/2024 12:11 pm, Andrew Cooper wrote:
> diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
> index d2efe9e11492..f45812483b8e 100644
> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -91,9 +91,15 @@ void relax_virtual_region_perms(void)
>
>
On 05/03/2024 12:44 pm, Jan Beulich wrote:
> On 05.03.2024 13:21, Andrew Cooper wrote:
>> This is bad copy/paste from somewhere. Retain the second _erodata symbol,
>> which follows the Build ID, and matches the other architectures.
>>
>> No functional change.
> I.e. the 2nd one took effect?
On 05.03.2024 13:21, Andrew Cooper wrote:
> This is bad copy/paste from somewhere. Retain the second _erodata symbol,
> which follows the Build ID, and matches the other architectures.
>
> No functional change.
I.e. the 2nd one took effect? (To be honest I'm surprised the linker
didn't complain
This is bad copy/paste from somewhere. Retain the second _erodata symbol,
which follows the Build ID, and matches the other architectures.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/arch/ppc/xen.lds.S | 1 -
flight 184907 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184907/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 184905
Tests which did not succeed,
These are optional. .init doesn't distinguish types of data like this, and
livepatches don't necesserily have any .rodata either.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
CC: Jan Beulich
CC: Roger Pau Monné
---
This capability was lost when fixing liveaptching vs CET, with a TODO to
fix...
Testing (In progress):
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1201429148
https://cirrus-ci.com/build/551009873576
Andrew Cooper (3):
xen/virtual-region: Rename start/end fields
This reinstates the capability to patch .rodata in load/unload hooks, which
was lost when we stopped using CR0.WP=0 to patch.
This turns out to be rather less of a large TODO than I thought at the time.
Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is
active")
... to text_{start,end}. We're about to introduce another start/end pair.
As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more consice
PAGE_ALIGN() ahead of duplicating the example.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
flight 184908 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184908/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2a0d4a2641a706d6b964dea0c95b1e0362194f57
baseline version:
ovmf
On 2024-02-29 18:05, Jan Beulich wrote:
On 29.02.2024 17:45, Nicola Vetrini wrote:
On 2024-02-29 17:37, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/irq.h
+++ b/xen/arch/x86/include/asm/irq.h
@@ -179,9 +179,9 @@ void
On 05.03.2024 11:21, Nicola Vetrini wrote:
> On 2024-02-29 23:49, Stefano Stabellini wrote:
>> On Thu, 29 Feb 2024, Nicola Vetrini wrote:
>>> On 2024-02-29 17:40, Jan Beulich wrote:
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/include/public/xen.h
> +++
On 2024-03-05 02:43, Stefano Stabellini wrote:
On Mon, 4 Mar 2024, Nicola Vetrini wrote:
Hi,
as the maintainers of this subsystem, would you prefer Jan's version
or the
one in the patch?
Both are fine w.r.t MISRA Rule 20.7 because the macro arguments
themselves are
parenthesized.
I
On 2024-02-29 23:53, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure
On 2024-02-29 23:49, Stefano Stabellini wrote:
On Thu, 29 Feb 2024, Nicola Vetrini wrote:
On 2024-02-29 17:40, Jan Beulich wrote:
> On 29.02.2024 16:27, Nicola Vetrini wrote:
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -988,7 +988,7 @@ typedef struct {
> >
On 05.03.2024 10:31, Roger Pau Monné wrote:
> On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
>> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
>> the lower 2Gb range and the top of the higher 2Gb range have special
>> purpose. Don't even have them influence
On 05.03.2024 10:25, Roger Pau Monné wrote:
> On Mon, Mar 04, 2024 at 02:25:45PM +0100, Jan Beulich wrote:
>> On 04.03.2024 11:02, Roger Pau Monné wrote:
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -33,6 +33,13 @@ uint32_t pci_mem_start =
On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> the lower 2Gb range and the top of the higher 2Gb range have special
> purpose. Don't even have them influence whether to (perhaps) relocate
> low RAM.
>
>
On 04.03.2024 10:13, Fouad Hilly wrote:
> X86 Xen will only eagerly switch FPU context in the scheduler.
> Xen itslef won't set CR0.TS other than for the purpose of servicing
> a PV guset.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Fouad Hilly
Throughout
On Mon, Mar 04, 2024 at 02:25:45PM +0100, Jan Beulich wrote:
> On 04.03.2024 11:02, Roger Pau Monné wrote:
> > On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> >> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> >> the lower 2Gb range and the top of the
On 04.03.2024 10:13, Fouad Hilly wrote:
> From: Wei Liu
>
> Previously FPU is lazily switched. Due to the fact that a malicious
> guest can speculatively read the not yet switched out register states,
> we need to eagerly switch FPU states when a domain is scheduled to
> run.
The speculation
On 04.03.2024 10:13, Fouad Hilly wrote:
> +void xstate_zero(uint64_t mask)
> +{
> +bool ok;
> +struct xsave_struct tmp;
> +
> +tmp.fpu_sse.mxcsr = MXCSR_DEFAULT;
This is a clear indication that the function name is wrong. Perhaps it is
"reset" that was meant?
> +
On 04.03.2024 10:13, Fouad Hilly wrote:
> From: Wei Liu
>
> No functional change
I don't think that's what's relevant to mention here. Saying that it's
trailing blanks and spelling which are taken care of would have clarified
what's to expect before even looking at the changes. I may decide to
On 26.02.2024 18:39, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
with one remark:
> +/*
> + * The following functions are defined in common/irq.c, which will be built
> in
> + * the next commit, so these changes will be removed there.
> + */
> +
> +void
There's no use of them anymore except in the definitions of the non-
underscore-prefixed aliases. Rename the inline functions, adjust the
virt_to_maddr() #define-e, and purge the (x86-only) maddr_to_virt() one,
thus eliminating a bogus cast which would have allowed the passing of a
pointer type
On 26.02.2024 18:39, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -3,11 +3,252 @@
> #ifndef _ASM_RISCV_MM_H
> #define _ASM_RISCV_MM_H
>
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> #include
>
>
On 26.02.2024 18:39, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/docs/misc/riscv/booting.txt
> @@ -0,0 +1,8 @@
> +System requirements
> +===
> +
> +The following extensions are expected to be supported by a system on which
> +Xen is run:
> +- Zihintpause:
> + On a system that
59 matches
Mail list logo
