FRED defines additional information in the upper 48 bits of cs/ss
fields. Therefore add the information definitions into the pt_regs
structure.
Specially introduce a new structure fred_ss to denote the FRED flags
above SS selector, which avoids FRED_SSX_ macros and makes the code
simpler and easie
From: "H. Peter Anvin (Intel)"
Add a header file for FRED prototypes and definitions.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v6:
* Replace pt_regs csx flags prefix FRED_CSL_ with FRED_CSX_.
---
arch/x86/include/asm/fred.h | 68
From: "H. Peter Anvin (Intel)"
MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to
be updated to point to the top of next task stack during task switch.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/switch_to.h | 8
Briefly introduce FRED, and its advantages compared to IDT.
Signed-off-by: Xin Li
---
Changes since v10:
* Reword a sentence to improve readability (Nikolay Borisov).
---
Documentation/arch/x86/x86_64/fred.rst | 96 +
Documentation/arch/x86/x86_64/index.rst | 1 +
2 fi
From: "H. Peter Anvin (Intel)"
Add X86_CR4_FRED macro for the FRED bit in %cr4. This bit must not be
changed after initialization, so add it to the pinned CR4 bits.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v9:
* Avoid a type cast by d
From: "H. Peter Anvin (Intel)"
ERETU returns from an event handler while making a transition to ring 3,
and ERETS returns from an event handler while staying in ring 0.
Add instruction opcodes used by ERET[US] to the x86 opcode map; opcode
numbers are per FRED spec v5.0.
Signed-off-by: H. Peter
From: "H. Peter Anvin (Intel)"
Add the configuration option CONFIG_X86_FRED to enable FRED.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/Kconfig | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
i
Add the opcode used by WRMSRNS, which is the non-serializing version of
WRMSR and may replace it to improve performance, to the x86 opcode map.
Tested-by: Shan Kang
Signed-off-by: Xin Li
Acked-by: Masami Hiramatsu (Google)
---
arch/x86/lib/x86-opcode-map.txt | 2 +-
tools/arch/x86/lib/x8
WRMSRNS is an instruction that behaves exactly like WRMSR, with
the only difference being that it is not a serializing instruction
by default. Under certain conditions, WRMSRNS may replace WRMSR to
improve performance.
Add the CPU feature bit for WRMSRNS.
Tested-by: Shan Kang
Signed-off-by: Xin
Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
into the code.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/msr.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 65
From: "H. Peter Anvin (Intel)"
When using FRED, reserve space at the top of the stack frame, just
like i386 does.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/thread_info.h | 12 +---
1 file changed, 9 insertions(+), 3 dele
struct pt_regs is hard to read because the member or section related
comments are not aligned with the members.
The 'cs' and 'ss' members of pt_regs are type of 'unsigned long' while
in reality they are only 16-bit wide. This works so far as the
remaining space is unused, but FRED will use the rem
From: "H. Peter Anvin (Intel)"
Add MSR numbers for the FRED configuration registers per FRED spec 5.0.
Originally-by: Megha Dey
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/msr-index.h | 13 -
tools/arch/x86/incl
From: "H. Peter Anvin (Intel)"
Update the objtool decoder to know about the ERET[US] instructions
(type INSN_CONTEXT_SWITCH).
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
tools/objtool/arch/x86/decode.c | 19 ++-
1 file changed, 14 inse
Intel VT-x classifies events into eight different types, which is
inherited by FRED for event identification. As such, event type
becomes a common x86 concept, and should be defined in a common x86
header.
Add event type macros to , and use it in .
Suggested-by: H. Peter Anvin (Intel)
Tested-by:
To enable FRED, a new kernel command line option "fred" needs to be added.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/x86/kernel/cpu/common.c| 3 +++
2 files changed, 6 insertions(+)
diff --git a/Documentatio
From: "H. Peter Anvin (Intel)"
Add CONFIG_X86_FRED to to make
cpu_feature_enabled() work correctly with FRED.
Originally-by: Megha Dey
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v10:
* FRED feature is defined in cpuid word 12, not 13
idtentry_sysvec is really just DECLARE_IDTENTRY defined in
, no need to define it separately.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/entry/entry_32.S | 4
arch/x86/entry/entry_64.S | 8
arch/x86/include/asm/idtentry.h | 2 +-
3 files changed, 1 inserti
This patch set enables the Intel flexible return and event delivery
(FRED) architecture for x86-64.
The FRED architecture defines simple new transitions that change
privilege level (ring transitions). The FRED architecture was
designed with the following goals:
1) Improve overall performance and
From: "H. Peter Anvin (Intel)"
Any FRED CPU will always have the following features as its baseline:
1) LKGS, load attributes of the GS segment but the base address into
the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor
cache.
2) WRMSRNS, non-serializing WRMSR for f
flight 183241 linux-linus real [real]
flight 183244 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183241/
http://logs.test-lab.xenproject.org/osstest/logs/183244/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 183242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183242/
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
Hi,
> On Oct 3, 2023, at 06:45, Stefano Stabellini wrote:
>
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Add missing parameter names. No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry Wang
Kind regards,
Henry
Hi,
> On Oct 3, 2023, at 06:46, Stefano Stabellini wrote:
>
> On Mon, 2 Oct 2023, Federico Serafini wrote:
>> Make function declaration and definition consistent.
>> No functional change.
>>
>> Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
Release-acked-by: Henry Wang
Hi Oleg,
You are getting this output:
> (XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
> f000
Which means that the guest physical address is 0x136bb000 and
the translated physical address is 0xf000. It generates an
error so you are asking if
On Mon, 2 Oct 2023, Julien Grall wrote:
> On 29/09/2023 21:29, Stefano Stabellini wrote:
> > I am very glad you managed to solve the issue!
> >
> > It is always difficult to know what is the right thing to do when the
> > firmware provides wrong or noncompliant information.
>
> I am a bit confuse
On Mon, 2 Oct 2023, Federico Serafini wrote:
> Make function declaration and definition consistent.
> No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The definition of 'consoled_guest_tx' can be static inline,
> thereby fixing a violation of MISRA C:2012 Rule 8.4.
>
> Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabel
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The declarations for {create,replace}_grant_p2m_mapping are
> not visible when these functions are defined, therefore the right
> header needs to be included to allow them to be visible.
>
> Signed-off-by: Nicola Vetrini
> ---
> xen/arch/x86/hvm/grant_
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> As stated in rules.rst, functions used only in asm code
> are allowed to have no prior declaration visible when being
> defined, hence these functions are deviated.
> This also fixes violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> These variables are only used by asm code, and therefore
> the lack of a declaration is justified by the corresponding
> SAF comment.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The headline of Directive 4.1 states: "Run-time failures shall be minimized".
> Thus, it requires the project to supply documentation that pertains the
> measures
> and techinques used to prevent run-time failures from happening. For ease of
> reading, t
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The documentation pertaining Directive 4.1 is contained in docs/misra.
> The build script driving the analysis is amended to allow ECLAIR to
> analyze such file.
>
> Signed-off-by: Nicola Vetrini
Acked-by: Stefano Stabellini
> ---
> Changes in v3:
>
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> To be able to check for the existence of the necessary subsections in
> the documentation for MISRA C:2012 Dir 4.1, ECLAIR needs to have a source
> file that is built.
>
> This file is generated from 'C-runtime-failures.rst' in docs/misra
> and the confi
On Mon, 2 Oct 2023, Nicola Vetrini wrote:
> The aforementioned directive requires the project to supply documentation
> on the measures taken towards the minimization of run-time failures.
>
> The actual content of the documentation still needs feedback from the
> community.
>
> The 'rules.rst' f
On Mon, 2 Oct 2023, Bertrand Marquis wrote:
> > On 2 Oct 2023, at 10:26, Julien Grall wrote:
> > On 29/09/2023 20:48, Stefano Stabellini wrote:
> >> On Fri, 29 Sep 2023, Luca Fancellu wrote:
> On 29 Sep 2023, at 01:33, Stefano Stabellini
> wrote:
>
> On Wed, 27 Sep 2023, Luc
Hi George,
Sebastien and others at Microchip would like to give an update about
their progress with Xen on RISC-V.
Cheers,
Stefano
On Mon, 2 Oct 2023, George Dunlap wrote:
> Hi all,
>
> The proposed agenda is in
> https://cryptpad.fr/pad/#/2/pad/edit/cQBSSCUBQj9es3-wcs7I+8Em/ and you
> can ed
Hi Stefano,
On 29/09/2023 21:29, Stefano Stabellini wrote:
I am very glad you managed to solve the issue!
It is always difficult to know what is the right thing to do when the
firmware provides wrong or noncompliant information.
I am a bit confused why you think the firmware is wrong here. Fr
flight 183240 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183240/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 3c0b315d79eb67846d99060e51989ff62bb33464
baseline version:
xtf cec23a34c03ffcf12d68d3
flight 183239 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183239/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1a66bd51ca21f341281d8e3157d3d3f4a94fd26c
baseline version:
ovmf f6a314e5b5dc969730874
flight 183236 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183236/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183234
test-amd64-amd64-xl-qemuu-win7-amd64
Hi,
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Int
Hi,
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in guest
On 02/10/2023 16:11, Roger Pau Monne wrote:
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest
From: Jan Beulich
The registration by virtual/linear address has downsides: The access is
expensive for HVM/PVH domains. Furthermore for 64-bit PV domains the area
is inaccessible (and hence cannot be updated by Xen) when in guest-user
mode.
Introduce a new vCPU operation allowing to register th
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the areas are inaccessible (and hence cannot be updated by
Xen) when in guest-user mode, and for HVM guests they may be
inacce
From: Jan Beulich
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary fork handling (with the
backing function yet to be filled in).
Signed-off-by: Jan Beulich
Signed-of
From: Jan Beulich
Switch to using map_guest_area(). Noteworthy differences from
map_vcpu_info():
- remote vCPU-s are paused rather than checked for being down (which in
principle can change right after the check),
- the domain lock is taken for a much smaller region,
- the error code for an att
From: Jan Beulich
The registration by virtual/linear address has downsides: At least on
x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
PV domains the area is inaccessible (and hence cannot be updated by Xen)
when in guest-user mode.
Introduce a new vCPU operation allowin
From: Jan Beulich
Before adding a new vCPU operation to register the runstate area by
guest-physical address, add code to actually keep such areas up-to-date.
Note that updating of the area will be done exclusively following the
model enabled by VMASST_TYPE_runstate_update_flag for virtual-addre
From: Jan Beulich
Before adding a new vCPU operation to register the secondary time area
by guest-physical address, add code to actually keep such areas up-to-
date.
Note that pages aren't marked dirty when written to (matching the
handling of space mapped by map_vcpu_info()), on the basis that
From: Jan Beulich
In preparation of the introduction of new vCPU operations allowing to
register the respective areas (one of the two is x86-specific) by
guest-physical address, add the necessary domain cleanup hooks.
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Acked-by: Roger Pau Mon
Instead let map_vcpu_info() and it's call to get_page_from_gfn()
populate the page in the child as needed. Also remove the bogus
copy_domain_page(): should be placed before the call to map_vcpu_info(),
as the later can update the contents of the vcpu_info page.
Note that this eliminates a bug in
Since it was indicated that introducing specific new vCPU ops may be
beneficial independent of the introduction of a fully physical-
address-based ABI flavor, here we go. There continue to be a few open
questions throughout the series, resolving of which was one of the main
goals of the earlier pos
From: Jan Beulich
While likely the guest would just re-register the same areas after
a possible resume, let's not take this for granted and avoid the risk of
otherwise corrupting guest memory.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
xen/arch/x86/pv/shim.c | 4
1 file cha
flight 183238 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183238/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f6a314e5b5dc9697308740b2ac391a3c21b26403
baseline version:
ovmf f36e1ec1f0a5fd3be8491
On Mon, Oct 02, 2023 at 10:55:28AM +0200, Joel Granados via B4 Relay wrote:
> From: Joel Granados
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which
> will reduce the overall build time size of the kernel a
Hi,
> On 2 Oct 2023, at 10:26, Julien Grall wrote:
>
> Hi Stefano,
>
> On 29/09/2023 20:48, Stefano Stabellini wrote:
>> On Fri, 29 Sep 2023, Luca Fancellu wrote:
On 29 Sep 2023, at 01:33, Stefano Stabellini
wrote:
On Wed, 27 Sep 2023, Luca Fancellu wrote:
> Currently
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/cQBSSCUBQj9es3-wcs7I+8Em/ and you
can edit to add items. Alternatively, you can reply to this mail
directly. I'll be running the meeting while Kelly is on PTO.
Agenda items appreciated a few days before the call: please put
Make function declaration and definition consistent.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/paging.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/paging.h
b/xen/arch/x86/include/asm/paging.h
index f291f
Link to v1:
> https://lore.kernel.org/r/20230928-jag-sysctl_remove_empty_elem_drivers-v1-0-e59120fca...@samsung.com
>
> Comments/feedback greatly appreciated
Same problem on powerpc CI tests, all boot target failed, most of them
with similar OOPS, see
https://patchwork.ozlabs.org/pro
On Thu, Sep 28, 2023 at 02:28:11PM -0400, Stewart Hildebrand wrote:
>
>
> On 9/28/23 04:28, Roger Pau Monné wrote:
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Sep 27, 2023 at 0
On Thu, Sep 28, 2023 at 01:48:59PM -0700, Stefano Stabellini wrote:
> On Thu, 28 Sep 2023, Roger Pau Monné wrote:
> > On Thu, Sep 28, 2023 at 11:32:22AM +0200, Jan Beulich wrote:
> > > On 28.09.2023 10:32, Roger Pau Monné wrote:
> > > > On Wed, Sep 27, 2023 at 04:20:04PM -0700, Stefano Stabellini w
On Sun, Oct 1, 2023 at 12:28 AM Demi Marie Obenour
wrote:
>
> On Fri, Sep 29, 2023 at 05:42:16PM +0100, George Dunlap wrote:
> > The basic credit2 algorithm goes something like this:
> >
> > 1. All vcpus start with the same number of credits; about 10ms worth
> > if everyone has the same weight
>
flight 183235 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183235/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in
183229
test-amd64-amd64-xl-qemu
On Mon, Oct 02, 2023 at 09:49:44AM +0200, Nicola Vetrini wrote:
> Some variables with external linkage used in C code do not have
> a visible declaration where they are defined. Providing such
> declaration also resolves violations of MISRA C:2012 Rule 8.4.
>
> Signed-off-by: Nicola Vetrini
> ---
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/irq.c | 3 ++-
xen/arch/x86/include/asm/irq.h | 4 ++--
xen/arch/x86/irq.c | 8
xen/include/xen/irq.h | 21 +++--
4 files changed, 19
On Fri, Sep 29, 2023 at 02:17:30PM +0200, Joel Granados wrote:
> On Thu, Sep 28, 2023 at 03:36:55PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 28, 2023 at 03:21:26PM +0200, Joel Granados via B4 Relay wrote:
> > > From: Joel Granados
> > >
> > > This commit comes at the tail end of a greater
Hello Stefano,
Hello Julien,
> OK I see the question is about the Xilinx Xen tree. In the logs below we
have:
I see. After the correction r2 to r1 CSU got aborted immediately.
(XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
f000
Received exception
MSR: 0x200, EAR:
Le 02/10/2023 à 10:47, Joel Granados a écrit :
> On Thu, Sep 28, 2023 at 04:31:30PM +, Christophe Leroy wrote:
> I followed this trace and proc_handler is correctly defined in tty_table
> (struct ctl_table) in drivers/tty/tty_io.c:tty_init and there is not
> path that changes these values.
>
On Mon, Oct 02, 2023 at 08:47:53AM +, Christophe Leroy wrote:
>
>
> Le 02/10/2023 à 10:17, Jiri Slaby a écrit :
> > On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
> >> From: Joel Granados
> >>
> >> This commit comes at the tail end of a greater effort to remove the
> >> empty elemen
On 02. 10. 23, 10:55, Joel Granados via B4 Relay wrote:
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
What?
These commits remove the sentinel element (last empty element) from the
sysctl arrays of all the files under the "drivers/" directory that use a
sysctl array for registration. The merging of the preparation patches
(in https://lore.kernel.org/all/zo5yx5jfoggi%2f...@bomba
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by ~64 bytes per sentinel (further information Link :
https:/
Hi Julien,
> On Oct 2, 2023, at 16:45, Julien Grall wrote:
>
> Hi,
>
> Adding Henry to release ack the patch.
Thanks.
>
> Cheers,
>
> On 28/09/2023 13:12, Ayan Kumar Halder wrote:
>> Change VPCU to vCPU.
>> Also add a space before '*/'.
>> Signed-off-by: Ayan Kumar Halder
>> Acked-by: Juli
Le 02/10/2023 à 10:17, Jiri Slaby a écrit :
> On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
>> From: Joel Granados
>>
>> This commit comes at the tail end of a greater effort to remove the
>> empty elements at the end of the ctl_table arrays (sentinels) which
>> will reduce the overall
On Thu, Sep 28, 2023 at 04:31:30PM +, Christophe Leroy wrote:
>
>
> Le 28/09/2023 à 15:21, Joel Granados via B4 Relay a écrit :
> > From: Joel Granados
>
> Automatic test fails on powerpc, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230928-jag-sysctl_remove_empty_elem_d
Hi,
Adding Henry to release ack the patch.
Cheers,
On 28/09/2023 13:12, Ayan Kumar Halder wrote:
Change VPCU to vCPU.
Also add a space before '*/'.
Signed-off-by: Ayan Kumar Halder
Acked-by: Julien Grall
---
Changes from -
v1 - 1. Change VCPU --> vCPU.
2. Add a space before '*/'.
xen/a
Hi,
On 29/09/2023 09:07, Henry Wang wrote:
On Sep 29, 2023, at 16:04, Juergen Gross wrote:
On 29.09.23 09:58, Julien Grall wrote:
From: Julien Grall
Signed-off-by: Julien Grall
---
README | 16
SUPPORT.md | 2 +-
xen/Makefile | 2 +-
3 files changed, 10 in
Hi Stefano,
On 29/09/2023 20:48, Stefano Stabellini wrote:
On Fri, 29 Sep 2023, Luca Fancellu wrote:
On 29 Sep 2023, at 01:33, Stefano Stabellini wrote:
On Wed, 27 Sep 2023, Luca Fancellu wrote:
Currently the dom0less feature code is mostly inside domain_build.c
and setup.c, it is a feature
On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
From: Joel Granados
This commit comes at the tail end of a greater effort to remove the
empty elements at the end of the ctl_table arrays (sentinels) which
will reduce the overall build time size of the kernel and run time
memory bloat by
On Wed 27-09-23 18:21:19, Christian Brauner wrote:
> On Wed, 27 Sep 2023 11:34:07 +0200, Jan Kara wrote:
> > Create struct bdev_handle that contains all parameters that need to be
> > passed to blkdev_put() and provide bdev_open_* functions that return
> > this structure instead of plain bdev point
The definition of 'consoled_guest_tx' can be static inline,
thereby fixing a violation of MISRA C:2012 Rule 8.4.
Fixes: 5ef49f185c2d ("x86/pv-shim: shadow PV console's page for L2 DomU")
Signed-off-by: Nicola Vetrini
---
xen/include/xen/consoled.h | 2 +-
1 file changed, 1 insertion(+), 1 deleti
The declarations for {create,replace}_grant_p2m_mapping are
not visible when these functions are defined, therefore the right
header needs to be included to allow them to be visible.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/grant_table.c | 3 +--
xen/arch/x86/include/asm/hv
Some variables with external linkage used in C code do not have
a visible declaration where they are defined. Providing such
declaration also resolves violations of MISRA C:2012 Rule 8.4.
Signed-off-by: Nicola Vetrini
---
xen/arch/arm/include/asm/setup.h | 3 +++
xen/arch/arm/include/asm/smp.h
1 - 100 of 111 matches
Mail list logo
