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
Because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER and
ERETU is the only legit instruction to return to ring 3, there is NO need
to setup SYSCALL and SYSENTER MSRs for FRED, except the IA32_STAR MSR.
Split IDT syscall setup code into idt_syscall_init() to make it easy to
skip
From: "H. Peter Anvin (Intel)"
When occurred on different ring level, i.e., from user or kernel context,
#DB needs to be handled on different stack: User #DB on current task
stack, while kernel #DB on a dedicated stack. This is exactly how FRED
event delivery invokes an exception handler: ring 3
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 -
From: "H. Peter Anvin (Intel)"
Because FRED always restores the full value of %rsp, ESPFIX is
no longer needed when it's enabled.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/kernel/espfix_64.c | 8
1 file changed, 8 insertions(+)
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
Add sysvec_install() to install a system interrupt handler into the IDT
or the FRED system interrupt handler table.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v8:
* Introduce a macro sysvec_install() to derive the asm handler name from
a C handler, which simplifies the code
From: "Peter Zijlstra (Intel)"
PUSH_AND_CLEAR_REGS could be used besides actual entry code; in that case
%rbp shouldn't be cleared (otherwise the frame pointer is destroyed) and
UNWIND_HINT shouldn't be added.
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
From: "H. Peter Anvin (Intel)"
On a FRED system, NMIs nest both with themselves and faults, transient
information is saved into the stack frame, and NMI unblocking only
happens when the stack frame indicates that so should happen.
Thus, the NMI entry stub for FRED is really quite small...
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
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)
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
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
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 |
From: "H. Peter Anvin (Intel)"
Let cpu_init_exception_handling() call cpu_init_fred_exceptions() to
initialize FRED. However if FRED is unavailable or disabled, it falls
back to set up TSS IST and initialize IDT.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Co-developed-by: Xin
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 its CPU feature bit, opcode to the x86 opcode map, and an
always inline
If the stack frame contains an invalid user context (e.g. due to invalid SS,
a non-canonical RIP, etc.) the ERETU instruction will trap (#SS or #GP).
>From a Linux point of view, this really should be considered a user space
failure, so use the standard fault fixup mechanism to intercept the
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.
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
From: "H. Peter Anvin (Intel)"
On a FRED system, the faulting address (CR2) is passed on the stack,
to avoid the problem of transient state. Thus the page fault address
is read from the FRED stack frame instead of CR2 when FRED is enabled.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan
Briefly introduce FRED, and its advantages compared to IDT.
Reviewed-by: Bagas Sanjaya
Signed-off-by: Xin Li
---
Changes since v10:
* Reword a sentence to improve readability (Nikolay Borisov).
---
Documentation/arch/x86/x86_64/fred.rst | 96 +
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)"
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
Hi Julien,
Thanks for the feedback. I'm answering the straightforward issues here
and saving the rest for the emerging thread.
On Mon, Dec 4, 2023 at 8:24 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 04/12/2023 07:55, Jens Wiklander wrote:
> > When an FF-A enabled guest is destroyed it may leave
On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
> > On Fri, Dec 01, 2023 at 06:56:32PM -0800, Stefano Stabellini wrote:
> > > On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> > > > On Mon, Nov 13, 2023 at 05:21:13PM -0500, Stewart
On 05/12/2023 11:42, Julien Grall wrote:
>
>
> On 05/12/2023 10:30, Michal Orzel wrote:
>>
>>
>> On 05/12/2023 11:01, Julien Grall wrote:
>>>
>>>
>>> On 05/12/2023 09:28, Michal Orzel wrote:
Hi Julien,
On 04/12/2023 20:55, Julien Grall wrote:
>
>
> On 04/12/2023
On 05/12/2023 8:14 am, Bertrand Marquis wrote:
> Hi Julien,
>
> Thanks a lot for your review and comment, this is very helpful.
>
>> On 4 Dec 2023, at 20:24, Julien Grall wrote:
>>
>> Hi Jens,
>>
>> On 04/12/2023 07:55, Jens Wiklander wrote:
>>>if ( ctx->rx )
>>> rxtx_unmap(ctx);
On 05/12/2023 10:30, Michal Orzel wrote:
On 05/12/2023 11:01, Julien Grall wrote:
On 05/12/2023 09:28, Michal Orzel wrote:
Hi Julien,
On 04/12/2023 20:55, Julien Grall wrote:
On 04/12/2023 13:02, Ayan Kumar Halder wrote:
On 04/12/2023 10:31, Julien Grall wrote:
Hi Ayan,
Hi
Update the Mini-OS upstream revision.
Signed-off-by: Juergen Gross
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index 594c70d8bb..c184add653 100644
--- a/Config.mk
+++ b/Config.mk
@@ -226,7 +226,7 @@ QEMU_UPSTREAM_URL ?=
On 05.12.2023 10:19, Roger Pau Monné wrote:
> On Mon, Dec 04, 2023 at 02:19:33PM -0800, Stefano Stabellini wrote:
>> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 07:37:55PM -0800, Stefano Stabellini wrote:
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Thu, Nov
On 05/12/2023 11:01, Julien Grall wrote:
>
>
> On 05/12/2023 09:28, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 04/12/2023 20:55, Julien Grall wrote:
>>>
>>>
>>> On 04/12/2023 13:02, Ayan Kumar Halder wrote:
On 04/12/2023 10:31, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
With include/xen/unaligned.h now dealing properly with unaligned
accesses for all architectures, asm/unaligned.h can be removed and
users can be switched to include xen/unaligned.h instead.
Signed-off-by: Juergen Gross
---
xen/arch/x86/include/asm/unaligned.h | 6 --
xen/common/lz4/defs.h
Update Xen's unaligned.h header to support all architectures, allowing
to remove the architecture specific variants (x86 only until now).
Juergen Gross (2):
xen: make include/xen/unaligned.h usable on all architectures
xen: remove asm/unaligned.h
xen/arch/x86/include/asm/unaligned.h | 6
Instead of defining get_unaligned() and put_unaligned() in a way that
is only supporting architectures allowing unaligned accesses, use the
same approach as the Linux kernel and let the compiler do the
decision how to generate the code for probably unaligned data accesses.
Update
On 05/12/2023 09:28, Michal Orzel wrote:
Hi Julien,
On 04/12/2023 20:55, Julien Grall wrote:
On 04/12/2023 13:02, Ayan Kumar Halder wrote:
On 04/12/2023 10:31, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 01/12/2023 18:50, Ayan Kumar Halder wrote:
Currently if user enables HVC_DCC
On 2023/12/5 17:19, Roger Pau Monné wrote:
> On Mon, Dec 04, 2023 at 02:19:33PM -0800, Stefano Stabellini wrote:
>> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 07:37:55PM -0800, Stefano Stabellini wrote:
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Thu, Nov
Hi Julien,
On 04/12/2023 20:55, Julien Grall wrote:
>
>
> On 04/12/2023 13:02, Ayan Kumar Halder wrote:
>>
>> On 04/12/2023 10:31, Julien Grall wrote:
>>> Hi Ayan,
>> Hi Julien,
>>>
>>> On 01/12/2023 18:50, Ayan Kumar Halder wrote:
Currently if user enables HVC_DCC config option in Linux,
Le mar. 5 déc. 2023 à 09:50, Sébastien Chaumat a écrit :
>
> Any direction on how I can enchance the debugging at the kernel level ?
>
> There was an old issue with amd_gpio there :
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971597
> Coud the kernel be confused by IRQ/GSI mapping ?
On Mon, Dec 04, 2023 at 02:19:33PM -0800, Stefano Stabellini wrote:
> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
> > On Fri, Dec 01, 2023 at 07:37:55PM -0800, Stefano Stabellini wrote:
> > > On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> > > > On Thu, Nov 30, 2023 at 07:15:17PM -0800, Stefano
flight 183989 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 183973
Tests which are
On 04.12.2023 18:27, Roger Pau Monné wrote:
> On Tue, Nov 28, 2023 at 11:34:04AM +0100, Jan Beulich wrote:
>> ..., at least as reasonably feasible without making a check hook
>> mandatory (in particular strict vs relaxed/zero-extend length checking
>> can't be done early this way).
>>
>> Note that
Any direction on how I can enhance the debugging at the kernel level ?
There was an old issue with amd_gpio there :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971597
Coud the kernel be confused by IRQ/GSI mapping ? Any way to test this
hypothesis?
Thanks
Le mar. 5 déc. 2023 à
On 05.12.2023 04:29, Stewart Hildebrand wrote:
> If rangeset_new() fails, err would not be set to an appropriate error
> code. Set it to -ENOMEM.
>
> Fixes: 580c458699e3 ("xen/domain: Call arch_domain_create() as early as
> possible in domain_create()")
> Signed-off-by: Stewart Hildebrand
On 04.12.2023 20:17, Sébastien Chaumat wrote:
> Le lun. 4 déc. 2023 à 10:06, Jan Beulich a écrit :
>
>> On 03.12.2023 10:56, Sébastien Chaumat wrote:
>>> Hello,
>>>
>>> Trying to get the Framework Laptop 13 AMD to work with QubesOS I hit the
>>> following Xen issue :
>>>
>>> Xen version :
Hi Julien,
Thanks a lot for your review and comment, this is very helpful.
> On 4 Dec 2023, at 20:24, Julien Grall wrote:
>
> Hi Jens,
>
> On 04/12/2023 07:55, Jens Wiklander wrote:
>> When an FF-A enabled guest is destroyed it may leave behind memory
>> shared with SPs. This memory must be
(reducing Cc list)
On 04.12.2023 22:31, Stefano Stabellini wrote:
> On Mon, 3 Dec 2023, Chen, Jiqian wrote:
vpci device state when device is reset on dom0 side.
And call that function in pcistub_init_device. Because when
we use "pci-assignable-add" to assign a passthrough
201 - 247 of 247 matches
Mail list logo
