On Wed, 2023-11-08 at 13:38 +, Nicolas Saenz Julienne wrote:
> On Wed Nov 8, 2023 at 12:45 PM UTC, Alexander Graf wrote:
> > On 08.11.23 12:18, Nicolas Saenz Julienne wrote:
> > > Introduce a new request type, KVM_REQ_HV_INJECT_INTERCEPT which allows
> > > injecting out-of-band Hyper-V secure i
On Mon, Oct 02, 2023 at 11:24:37PM -0700, Xin Li wrote:
> 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
On Mon, Oct 02, 2023 at 11:24:41PM -0700, Xin Li wrote:
> + * Note, LKGS loads the GS base address into the IA32_KERNEL_GS_BASE
> + * MSR instead of the GS segment’s descriptor cache. As such, the
:verify_diff: WARNING: Unicode char [’] (0x8217 in line: + * MSR instead of
the GS seg
On Mon, Oct 02, 2023 at 11:24:45PM -0700, Xin Li wrote:
> FRED and IDT can share most of the definitions and declarations so
> that in the majority of cases the actual handler implementation is the
> same.
>
> The differences are the exceptions where FRED stores exception related
> information on
On 11/27/2023 5:04 PM, Pavan Kondeti wrote:
On Sat, Nov 25, 2023 at 03:49:53AM +0530, Mukesh Ojha wrote:
The reserved memory region for ramoops is assumed to be at a fixed
and known location when read from the devicetree. This may not be
required for something like Qualcomm's minidump which i
XFS docs are currently in upper-level Documentation/filesystems.
Although these are currently 4 docs, they are already outstanding as
a group and can be moved to its own subdirectory.
Consolidate them into Documentation/filesystems/xfs/.
Signed-off-by: Bagas Sanjaya
---
Changes since v1 [1]:
On 24/11/2023 22:19, Mukesh Ojha wrote:
Add the qualcomm minidump guide for the users which tries to cover
the dependency, API use and the way to test and collect minidump
on Qualcomm supported SoCs.
Signed-off-by: Mukesh Ojha
---
Documentation/admin-guide/index.rst | 1 +
Document
On Mon, Nov 27, 2023 at 11:41:31AM -0800, Randy Dunlap wrote:
> Hi,
>
> On 11/27/23 07:57, attreyee-muk wrote:
> > Respected Maintainers,
> >
> > I have made some grammatical changes in the livepatch.rst file where I
> > felt that the sentence would have sounded more correct and would have
> >
On Tue, 07 Nov 2023 10:29:23 +
Russell King wrote:
> From: James Morse
>
> register_cpu_capacity_sysctl() adds a property to sysfs that describes
> the CPUs capacity. This is done from a subsys_initcall() that assumes
> all possible CPUs are registered.
>
> With CPU hotplug, possible CPUs
On Tue, 07 Nov 2023 10:29:33 +
"Russell King (Oracle)" wrote:
> arch_register_cpu() and arch_unregister_cpu() are not used by anything
> that can be a module - they are used by drivers/base/cpu.c and
> drivers/acpi/acpi_processor.c, neither of which can be a module.
>
> Remove the exports.
>
On Tue, 07 Nov 2023 10:29:44 +
Russell King wrote:
> From: James Morse
>
> Neither arm64 nor riscv support physical hotadd of CPUs that were not
> present at boot. For arm64 much of the platform description is in static
> tables which do not have update methods. arm64 does support HOTPLUG_C
On Tue, 07 Nov 2023 10:30:04 +
"Russell King (Oracle)" wrote:
> The differences between architecture specific implementations of
> arch_register_cpu() are down to whether the CPU is hotpluggable or not.
> Rather than overriding the weak version of arch_register_cpu(), provide
> a function tha
On Tue, 28 Nov 2023 13:55:36 +
Jonathan Cameron wrote:
> On Tue, 21 Nov 2023 13:27:08 +
> "Russell King (Oracle)" wrote:
>
> > On Mon, Nov 13, 2023 at 08:00:19AM +, Russell King (Oracle) wrote:
> > > On Mon, Nov 13, 2023 at 10:58:46AM +1000, Gavin Shan wrote:
> > > >
> > > >
On Tue, 07 Nov 2023 10:30:20 +
Russell King wrote:
> From: James Morse
>
> loongarch, mips, parisc, riscv and sh all print a warning if
> register_cpu() returns an error. Architectures that use
> GENERIC_CPU_DEVICES call panic() instead.
>
> Errors in this path indicate something is wrong
On Tue, 07 Nov 2023 10:30:25 +
Russell King wrote:
> From: James Morse
>
> To allow ACPI's _STA value to hide CPUs that are present, but not
> available to online right now due to VMM or firmware policy, the
> register_cpu() call needs to be made by the ACPI machinery when ACPI
> is in use.
On Tue, 07 Nov 2023 10:30:30 +
"Russell King (Oracle)" wrote:
> Convert arm64 to use the arch_cpu_is_hotpluggable() helper rather than
> arch_register_cpu().
>
> Signed-off-by: Russell King (Oracle)
Ah. Or previous patch needs a forwards reference to the tweaking
of it it here.
Maybe just
On Tue, 07 Nov 2023 10:30:40 +
"Russell King (Oracle)" wrote:
> Since the x86 version of arch_unregister_cpu() is the same as the weak
> version, drop the x86 specific version.
>
> Signed-off-by: Russell King (Oracle)
Reviewed-by: Jonathan Cameron
On Tue, 07 Nov 2023 10:30:45 +
"Russell King (Oracle)" wrote:
> Convert x86 to use the arch_cpu_is_hotpluggable() helper rather than
> arch_register_cpu().
>
> Signed-off-by: Russell King (Oracle)
Reviewed-by: Jonathan Cameron
As with earlier set of related changes, could squash this down
On Tue, 07 Nov 2023 10:31:01 +
"Russell King (Oracle)" wrote:
> Convert loongarch to use the arch_cpu_is_hotpluggable() helper rather
> than arch_register_cpu(). Also remove the export as nothing should be
> using arch_register_cpu() outside of the core kernel/acpi code.
>
> Signed-off-by: R
On Tue, 07 Nov 2023 10:31:11 +
"Russell King (Oracle)" wrote:
> Convert riscv to use the arch_cpu_is_hotpluggable() helper rather than
> arch_register_cpu().
>
> Signed-off-by: Russell King (Oracle)
Reviewed-by: Jonathan Cameron
Thanks for driving this forwards.
Jonathan
On Tue, Nov 28, 2023 at 02:37:22PM +, Jonathan Cameron wrote:
> On Tue, 07 Nov 2023 10:29:23 +
> Russell King wrote:
>
> > From: James Morse
> >
> > register_cpu_capacity_sysctl() adds a property to sysfs that describes
> > the CPUs capacity. This is done from a subsys_initcall() that a
On Tue, Nov 28, 2023 at 02:40:59PM +, Jonathan Cameron wrote:
> On Tue, 07 Nov 2023 10:29:28 +
> Russell King wrote:
>
> > From: James Morse
> >
> > intel_epb_init() is called as a subsys_initcall() to register cpuhp
> > callbacks. The callbacks make use of get_cpu_device() which will r
On Tue, Nov 28, 2023 at 04:02:33PM +0530, Mukesh Ojha wrote:
> > > static int ramoops_pstore_open(struct pstore_info *psi)
> > > {
> > > @@ -915,14 +965,18 @@ static void __init ramoops_register_dummy(void)
> > > /*
> > >* Prepare a dummy platform data structure to carry t
On 11/28/23 06:12, Matthew Wilcox wrote:
> On Mon, Nov 27, 2023 at 11:41:31AM -0800, Randy Dunlap wrote:
>> Hi,
>>
>> On 11/27/23 07:57, attreyee-muk wrote:
>>> Respected Maintainers,
>>>
>>> I have made some grammatical changes in the livepatch.rst file where I
>>> felt that the sentence would
On Tue, Nov 28, 2023, Maxim Levitsky wrote:
> On Wed, 2023-11-08 at 11:17 +, Nicolas Saenz Julienne wrote:
> > Include the fault's read, write and execute status when exiting to
> > user-space.
> >
> > Signed-off-by: Nicolas Saenz Julienne
> > ---
> > arch/x86/kvm/mmu/mmu.c | 4 ++--
> > i
> > FRED and IDT can share most of the definitions and declarations so
> > that in the majority of cases the actual handler implementation is the
> > same.
> >
> > The differences are the exceptions where FRED stores exception related
> > information on the stack and the sysvec implementations as F
On Tue, Nov 28, 2023 at 10:58:50AM -0800, H. Peter Anvin wrote:
> >You have a very good sense 😊
I've been reading code of a couple of people for a couple of years. :-)
> Remember that Signed-off-by: relates to the *patch flow*.
Yes, you should take the time to read Documentation/process/ and
esp
Hello Krzysztof,
On 2023-11-25 19:44, Krzysztof Kozlowski wrote:
Document preferred coding style for Devicetree sources (DTS and DTSI),
to bring consistency among all (sub)architectures and ease in reviews.
Cc: Andrew Davis
cc: Andrew Lunn
Cc: AngeloGioacchino Del Regno
Cc: Arnd Bergmann
On Tue, Nov 28, 2023 at 08:32:55AM -0800, Darrick J. Wong wrote:
> On Tue, Nov 28, 2023 at 07:45:22PM +0700, Bagas Sanjaya wrote:
> > XFS docs are currently in upper-level Documentation/filesystems.
> > Although these are currently 4 docs, they are already outstanding as
> > a group and can be move
On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
Thank Krzysztof, we had most of this collected as BKM in some internal
documents an
30 matches
Mail list logo
