Borislav Petkov writes:
> On Mon, Dec 14, 2020 at 10:27:09PM +0900, Punit Agrawal wrote:
>> IIUC, this suggests that Linux booting on anything prior to Zen3 is down
>> to pure luck - I hope that wasn't the case.
>
> WTF does this have to do with linux booting?!
I
Borislav Petkov writes:
> On Sat, Dec 12, 2020 at 08:36:48AM +0900, Punit Agrawal wrote:
>> To me it suggests, that there are likely more systems from the family
>> that show the characteristic described below.
>
> Until we find a *single* system with a broken BIOS whic
Borislav Petkov writes:
> On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
>> According to the commit log, acd316248205 seems to be only targeted at
>> powernow-K8 -
>
> No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
> on AMD h
Borislav Petkov writes:
> On Fri, Dec 11, 2020 at 07:56:40AM +0900, Punit Agrawal wrote:
>> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
>> stepping: 0x1) shows the following message in the logs -
>>
>> acpi_cpufreq: overriding BIOS provide
e override is not required for Zen3
onwards, it seems that domain information can be trusted even on
certain earlier systems. Update the check, to skip the override for
Zen2 processors known to work without the override.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpu
value of the function to bool
Punit Agrawal (2):
cpufreq: acpi-cpufreq: Re-factor overriding ACPI PSD
cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list
drivers/cpufreq/acpi-cpufreq.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
--
2.29.2
Re-factor the code to override the firmware provided frequency domain
information (via PSD) to localise the checks in one function.
No functional change intended.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 17 +++--
1 file changed, 15
interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +};
> + };
> +...
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
Rob Herring writes:
[...]
>> > + gpio-ranges: true
>>
>> I am not sure I have a good handle on the yaml schema definitions but
>> "gpio-ranges" feels like it should be a list of ranges not a boolean.
>>
>> Something like -
>>
>> gpio-ranges:
>> maxItems: 1
>>
>> feels more
Hi Wei,
Wei Huang writes:
> On 11/25/20 8:48 AM, Punit Agrawal wrote:
>> Re-factor the code to override the firmware provided frequency domain
>> information (via PSD) to localise the checks in one function.
>>
>> No functional change intended.
>>
>> S
Hi Rafael,
"Rafael J. Wysocki" writes:
> On Fri, Dec 4, 2020 at 11:45 PM Punit Agrawal wrote:
>>
>> Hi Rafael,
>>
>> Punit Agrawal writes:
>>
>> > Hi,
>> >
>> > While looking into Giovanni's patches to enable frequency i
Borislav Petkov writes:
> On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
>> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
>> there are two approaches:
>>
>> * Keep override_acpi_psd()
>> Let us keep the original quirk and override_acpi_psd() function. Over
>>
Hi Rafael,
Punit Agrawal writes:
> Hi,
>
> While looking into Giovanni's patches to enable frequency invariance
> on AMD systems[0], I noticed an issue with initialising frequency
> domain information on a recent AMD APU.
>
> Patch 1 refactors the test to ignore firmwa
ss-cells = <2>;
> #size-cells = <2>;
> @@ -384,6 +390,12 @@ spi6: spi@28146000 {
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + wdt: wdt@28330000 {
> + compatible = "toshiba,visconti-wdt";
> + reg = <0 0x2833 0 0x1000>;
> + status = "disabled";
> + };
> };
> };
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> uart0: serial@2820 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0 0x2820 0 0x1000>;
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
+ struct irq_desc *desc;
> + struct gpio_irq_chip *girq;
> + const char *name = dev_name(dev);
> + int i, ret, num_irq;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev
Iwamatsu-san,
Nobuhiro Iwamatsu writes:
> Add bindings for the Toshiba Visconti GPIO Controller.
>
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> .../bindings/gpio/toshiba,gpio-visconti.yaml | 85 +++
> 1 file changed, 85 insertions(+)
> create mode 100644
>
Borislav Petkov writes:
> On Wed, Nov 25, 2020 at 11:48:47PM +0900, Punit Agrawal wrote:
>> Replace the raw values for AMD processor family with recently
>> introduced identifier macros to improve code readability and
>> maintainability.
>>
>> Signed-off-by:
Hi Boris,
Borislav Petkov writes:
> On Wed, Nov 25, 2020 at 11:48:46PM +0900, Punit Agrawal wrote:
>> So far, the AMD processor identifier (family, models, stepping) are
>> referred to by raw values making it easy to make mistakes. It is also
>> harder to read and m
with the processor identifiers.
As a first step towards improving the status quo, add macros for the
AMD processor families and propagate them through the existing
cpu_device_id.h header used for this purpose.
Signed-off-by: Punit Agrawal
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x
e override is not required for Zen3
onwards, it seems that domain information can be trusted even on
certain earlier systems. Update the check, to skip the override for
Zen2 processors known to work without the override.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpu
Replace the raw values for AMD processor family with recently
introduced identifier macros to improve code readability and
maintainability.
Signed-off-by: Punit Agrawal
---
drivers/cpufreq/acpi-cpufreq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq
independent and a first step towards
improving the situation with regards to the use of raw identifiers for
AMD processors throughout the kernel.
All feedback welcome.
Thanks,
Punit
[0]
https://lore.kernel.org/linux-acpi/20201112182614.10700-1-ggherdov...@suse.cz/
Punit Agrawal (4):
cpufreq
Re-factor the code to override the firmware provided frequency domain
information (via PSD) to localise the checks in one function.
No functional change intended.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 17 +++--
1 file changed, 15
and again when matching cpus
belonging to the same domain.
Drop the unnecessary initialisation.
Signed-off-by: Punit Agrawal
---
drivers/acpi/processor_perflib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index
Smita Koralahalli Channabasappa writes:
> Punit,
>
> On 11/9/20 1:05 PM, Smita Koralahalli Channabasappa wrote:
>
>> On 11/8/20 7:18 PM, Punit Agrawal wrote:
>>> Borislav Petkov writes:
>>>> On Fri, Nov 06, 2020 at 02:36:46PM +0900, Punit Agrawal wrote:
&
Borislav Petkov writes:
> On Fri, Nov 06, 2020 at 02:36:46PM +0900, Punit Agrawal wrote:
>> > diff --git a/drivers/firmware/efi/cper-x86.c
>> > b/drivers/firmware/efi/cper-x86.c
>> > index 2531de49f56c..438ed9eff6d0 100644
>> > --- a/drivers/firmware/efi
print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16,
> +groupsize, (ctx_info + 1),
> + ctx_info->reg_arr_size, 0);
> + }
>
> ctx_info = (struct cper_ia_proc_ctx *)((long)ctx_info + size);
> }
With that addressed,
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
Yazen Ghannam writes:
> On Fri, Sep 25, 2020 at 09:54:06AM +0900, Punit Agrawal wrote:
>> Borislav Petkov writes:
>>
>> > On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa
>> > wrote:
>> >> > Even though it
Borislav Petkov writes:
> On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa
> wrote:
>> > Even though it's not defined in the UEFI spec, it doesn't mean a
>> > structure definition cannot be created.
>
> Created for what? That structure better have a big fat comment
Sep 2020 14:49:12
> +
> ^^
>
> On Wed, Sep 23, 2020 at 07:07:17PM +0900, Punit Agrawal wrote:
>> I know Boris asked you to add the reason for the Reported-by, but
>> usually we don't track version differences in the committed patch.
>
Hi Smita,
A few comments below.
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
> format.
Ben Levinsky writes:
> Hi All,
>
>> -Original Message-
>> From: Wendy Liang
>> Sent: Friday, September 18, 2020 6:53 PM
>> To: Michael Auchter
>> Cc: Ben Levinsky ; punit1.agra...@toshiba.co.jp;
>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
>>
Hi Ben,
One query below -
Ben Levinsky writes:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
>
> Signed-off-by: Jason Wu
> Signed-off-by: Wendy Liang
> Signed-off-by: Michal Simek
Hi Amit,
Amit Sunil Dhamne writes:
> From: Tejas Patel
>
> Validate IOCTL ID for ZynqMP and Versal before calling
> zynqmp_pm_invoke_fn().
>
> Signed-off-by: Tejas Patel
> Signed-off-by: Amit Sunil Dhamne
> ---
> drivers/firmware/xilinx/zynqmp.c | 117
>
Hi Ben,
Thanks for fixing the commit ordering issue. Some additional comments
below.
Ben Levinsky writes:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different 2
> configurations: split or lock-step.
Suggest following
Hi Ben,
Thanks for addressing the comments on the previous version. One comment
below.
Ben Levinsky writes:
> This patch adds APIs to access to configure RPU and its
> processor-specific memory.
>
> That is query the run-time mode of RPU as either split or lockstep as well
> as API to set this
Ben Levinsky writes:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different 2
> configurations: split or lock-step.
>
> The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> Platform Management Unit
Hi Ben,
Noticed some issues while going through the code. A couple of queries
below.
Ben Levinsky writes:
> This patch adds APIs to access to configure RPU and its
> processor-specific memory.
>
> That is query the run-time mode of RPU as either split or lockstep as well
> as API to set this
Hi Smita,
Smita Koralahalli Channabasappa writes:
> On 8/31/20 12:05 AM, Punit Agrawal wrote:
>
>> Hi Smita,
>>
>> A couple of comments below -
>>
>> Smita Koralahalli writes:
>>
>> [...]
>>
>>
>>> diff --git a/drivers/fir
Hi Smita,
A couple of comments below -
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
>
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 3d8c11efd528d56972d44ed0de51c4e11a9a4fa9
Gitweb:
https://git.kernel.org/tip/3d8c11efd528d56972d44ed0de51c4e11a9a4fa9
Author:Punit Agrawal
AuthorDate:Tue, 12 May 2020 13:55:02 +09:00
Hi Aaron,
"Brown, Aaron F" writes:
>> From: netdev-ow...@vger.kernel.org On
>> Behalf Of Punit Agrawal
>> Sent: Thursday, May 14, 2020 9:31 PM
>> To: Kirsher, Jeffrey T
>> Cc: daniel.sangor...@toshiba.co.jp; Punit Agrawal
>> ; Alexand
. The extra condition can lead to inconsistency between the
state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
While at it, also make __ew32_prepare() static as it's not used
anywhere else.
Signed-off-by: Punit Agrawal
Reviewed-by: Alexander Duyck
Alexander Duyck writes:
> On Mon, May 11, 2020 at 9:45 PM Punit Agrawal
> wrote:
>>
>> It's an error if the value of the RX/TX tail descriptor does not match
>> what was written. The error condition is true regardless the duration
>> of the interference from
Ard Biesheuvel writes:
> On Tue, 12 May 2020 at 06:55, Punit Agrawal
> wrote:
>>
>> While debugging a boot failure, the following unknown error record was
>> seen in the boot logs.
>>
>> <...>
>> BERT: Error records from previous boot
ion at least since v2.4 and has recently had additional
fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.
Add support for parsing and printing the defined fields to give users
a chance to figure out what went wrong.
Signed-off-by: Punit Agrawal
Cc: Ard Biesheuvel
Cc: "
condition can lead to inconsistency between the
state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
Signed-off-by: Punit Agrawal
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.ker
Hi Ard,
Ard Biesheuvel writes:
> Hello Punit,
>
> On Mon, 27 Apr 2020 at 11:03, Punit Agrawal
> wrote:
>>
>> While debugging a boot failure, the following unknown error record was
>> seen in the boot logs.
>>
>> <...>
>> BERT: Er
Christoffer Dall writes:
> On Tue, Dec 11, 2018 at 05:10:33PM +, Suzuki K Poulose wrote:
>> This series is an update to the PUD hugepage support previously posted
>> at [0]. This patchset adds support for PUD hugepages at stage 2 a
>> feature that is useful on cores that have support for
As I'll no longer be working with Arm, add a mailmap entry so any mail
directed towards me reaches the appropriate mailbox.
Signed-off-by: Punit Agrawal
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index a76be45fef6c..28fecafa6506 100644
--- a/.mailmap
As I'll no longer be working with Arm, add a mailmap entry so any mail
directed towards me reaches the appropriate mailbox.
Signed-off-by: Punit Agrawal
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index a76be45fef6c..28fecafa6506 100644
--- a/.mailmap
Randy Dunlap writes:
> On 10/8/18 3:03 AM, Punit Agrawal wrote:
>> Arm v8 architecture supports multiple page sizes - 4k, 16k and
>> 64k. Based on the active page size, the Linux port supports
>> corresponding hugepage sizes at PMD and PUD(4k only) levels.
>>
>&
Randy Dunlap writes:
> On 10/8/18 3:03 AM, Punit Agrawal wrote:
>> Arm v8 architecture supports multiple page sizes - 4k, 16k and
>> 64k. Based on the active page size, the Linux port supports
>> corresponding hugepage sizes at PMD and PUD(4k only) levels.
>>
>&
Hi Lukas,
Lukas Braun writes:
> Userspace can create a memslot with memory backed by (transparent)
> hugepages, but with bounds that do not align with hugepages.
> In that case, we cannot map the entire region in the guest as hugepages
> without exposing additional host memory to the guest and
Hi Lukas,
Lukas Braun writes:
> Userspace can create a memslot with memory backed by (transparent)
> hugepages, but with bounds that do not align with hugepages.
> In that case, we cannot map the entire region in the guest as hugepages
> without exposing additional host memory to the guest and
Marc Zyngier writes:
> Hi Punit,
>
> On 01/10/18 16:54, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
&g
Marc Zyngier writes:
> Hi Punit,
>
> On 01/10/18 16:54, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
&g
Anshuman Khandual writes:
> ARM64 architecture also supports 32MB and 512MB HugeTLB page sizes.
> This just adds mmap() system call argument encoding for them.
>
> Signed-off-by: Anshuman Khandual
Thanks for adding the encodings.
Acked-by: Punit Agrawal
> ---
>
> Chang
Anshuman Khandual writes:
> ARM64 architecture also supports 32MB and 512MB HugeTLB page sizes.
> This just adds mmap() system call argument encoding for them.
>
> Signed-off-by: Anshuman Khandual
Thanks for adding the encodings.
Acked-by: Punit Agrawal
> ---
>
> Chang
* (100)^2 = 10^15 mW
> which is not realistic
>
> With the unit used by the code, the min power is
> min power = 1 * 1000 * 1^2 = 1000uW = 1mW which is far more realistic
>
> Signed-off-by: Vincent Guittot
Acked-by: Punit Agrawal
Thanks for fixing the mismatch.
> ---
>
* (100)^2 = 10^15 mW
> which is not realistic
>
> With the unit used by the code, the min power is
> min power = 1 * 1000 * 1^2 = 1000uW = 1mW which is far more realistic
>
> Signed-off-by: Vincent Guittot
Acked-by: Punit Agrawal
Thanks for fixing the mismatch.
> ---
>
additional context.
Drop the node local allocation as there is no benefit from doing so -
the usage of these structures is independent from where the controller
is located.
Signed-off-by: Punit Agrawal
Cc: Bjorn Helgaas
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arc
are based on v4.19-rc1 and has been boot tested on arm64
and compile tested on x86.
Thanks,
Punit
[0] https://www.spinics.net/lists/arm-kernel/msg669746.html
Punit Agrawal (2):
arm64: PCI: Remove node-local allocations when initialising host
controller
x86/PCI: Remove node-local allocation
additional context.
Drop the node local allocation as there is no benefit from doing so -
the usage of these structures is independent from where the controller
is located.
Signed-off-by: Punit Agrawal
Cc: Bjorn Helgaas
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arc
are based on v4.19-rc1 and has been boot tested on arm64
and compile tested on x86.
Thanks,
Punit
[0] https://www.spinics.net/lists/arm-kernel/msg669746.html
Punit Agrawal (2):
arm64: PCI: Remove node-local allocations when initialising host
controller
x86/PCI: Remove node-local allocation
allocation as there is no benefit from doing so -
the usage of these structures is independent from where the controller
is located.
Signed-off-by: Punit Agrawal
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Lorenzo Pieralisi
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/kernel/pci.c | 5 ++-
allocation as there is no benefit from doing so -
the usage of these structures is independent from where the controller
is located.
Signed-off-by: Punit Agrawal
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Lorenzo Pieralisi
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/kernel/pci.c | 5 ++-
Vincent Guittot writes:
> Hi Amit,
>
> On Wed, 22 Aug 2018 at 12:11, Punit Agrawal wrote:
>>
>> Hi Vincent,
>>
>> Thanks for the patch. One comment about the choice of units below.
>>
>> Vincent Guittot writes:
>>
>> > The unit of d
Vincent Guittot writes:
> Hi Amit,
>
> On Wed, 22 Aug 2018 at 12:11, Punit Agrawal wrote:
>>
>> Hi Vincent,
>>
>> Thanks for the patch. One comment about the choice of units below.
>>
>> Vincent Guittot writes:
>>
>> > The unit of d
Hi Vincent,
Thanks for the patch. One comment about the choice of units below.
Vincent Guittot writes:
> The unit of dynamic-power-coefficient is described as mW/MHz/uV^2 whereas
> its usage in the code assumes that unit is mW/GHz/V^2
Instead of choosing GHz as the base, I'd prefer to use
Hi Vincent,
Thanks for the patch. One comment about the choice of units below.
Vincent Guittot writes:
> The unit of dynamic-power-coefficient is described as mW/MHz/uV^2 whereas
> its usage in the code assumes that unit is mW/GHz/V^2
Instead of choosing GHz as the base, I'd prefer to use
Bjorn Helgaas writes:
> On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote:
>> Bjorn Helgaas writes:
>> > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi
>> > wrote:
>> >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wro
Bjorn Helgaas writes:
> On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote:
>> Bjorn Helgaas writes:
>> > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi
>> > wrote:
>> >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wro
ang Lui
>>
>> Jiang Liu does not work on the kernel anymore so we won't know
>> anytime soon the reasoning behind commit 965cd0e4a5e5
>>
>> > On 08/01/2018 12:31 PM, Punit Agrawal wrote:
>> > >Memory for host controller data structures is allocated local to th
ang Lui
>>
>> Jiang Liu does not work on the kernel anymore so we won't know
>> anytime soon the reasoning behind commit 965cd0e4a5e5
>>
>> > On 08/01/2018 12:31 PM, Punit Agrawal wrote:
>> > >Memory for host controller data structures is allocated local to th
[4/4]
v1 -> v2:
* Create helper to check if the page should have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg664276.html
[1] https://www.spinics.net/lists/kvm/ms
[4/4]
v1 -> v2:
* Create helper to check if the page should have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg664276.html
[1] https://www.spinics.net/lists/kvm/ms
ld have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Share
ld have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Share
ld have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Share common code in us
ld have exec permission [1/4]
* Fix broken condition to detect THP hugepage [1/4]
* Fix in-correct hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Share common code in us
Suzuki K Poulose writes:
> Hi Punit,
>
> On 05/07/18 15:08, Punit Agrawal wrote:
>> KVM only supports PMD hugepages at stage 2. Now that the various page
>> handling routines are updated, extend the stage 2 fault handling to
>> map in PUD hugepages.
>>
>> A
Suzuki K Poulose writes:
> Hi Punit,
>
> On 05/07/18 15:08, Punit Agrawal wrote:
>> KVM only supports PMD hugepages at stage 2. Now that the various page
>> handling routines are updated, extend the stage 2 fault handling to
>> map in PUD hugepages.
>>
>> A
Marc Zyngier writes:
> Hi Punit,
>
> On 05/07/18 15:08, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
Marc Zyngier writes:
> Hi Punit,
>
> On 05/07/18 15:08, Punit Agrawal wrote:
>> The code for operations such as marking the pfn as dirty, and
>> dcache/icache maintenance during stage 2 fault handling is duplicated
>> between normal pages and PMD hugepages.
>>
Hi,
Nightly LTP runs are hitting a use-after-free on upstream kernels when
running with 64k pages. There isn't a specific test triggering the
issue. Also, the problem is not encountered with 4k pages.
The boards used for the nightly runs mount their filesystem (Debian
Jessie) via NFS with the
Hi,
Nightly LTP runs are hitting a use-after-free on upstream kernels when
running with 64k pages. There isn't a specific test triggering the
issue. Also, the problem is not encountered with 4k pages.
The boards used for the nightly runs mount their filesystem (Debian
Jessie) via NFS with the
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on
Jonathan Cameron writes:
[...]
>
> I'll test it when back in the office, but I had a similar issue with
> memory only nodes when I moved the SRAT listing for cpus from the 4
> 4th mode to the 3rd node to fake some memory I could hot unplug.
> This gave a memory only node for the last node on
Michal Hocko writes:
> On Fri 22-06-18 16:58:05, Hanjun Guo wrote:
>> On 2018/6/20 19:51, Punit Agrawal wrote:
>> > Xie XiuQi writes:
>> >
>> >> Hi Lorenzo, Punit,
>> >>
>> >>
>> >> On 2018/6/20 0:32, Lorenzo Pieralisi
Michal Hocko writes:
> On Fri 22-06-18 16:58:05, Hanjun Guo wrote:
>> On 2018/6/20 19:51, Punit Agrawal wrote:
>> > Xie XiuQi writes:
>> >
>> >> Hi Lorenzo, Punit,
>> >>
>> >>
>> >> On 2018/6/20 0:32, Lorenzo Pieralisi
Hi,
Mawanda Henry writes:
> SPDX license helps developers and machines to know the license governing
> a particular file hence easing work
>
> Signed-off-by: Mawanda Henry
> ---
> drivers/bus/arm-cci.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git
Hi,
Mawanda Henry writes:
> SPDX license helps developers and machines to know the license governing
> a particular file hence easing work
>
> Signed-off-by: Mawanda Henry
> ---
> drivers/bus/arm-cci.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git
Xie XiuQi writes:
> Hi Lorenzo, Punit,
>
>
> On 2018/6/20 0:32, Lorenzo Pieralisi wrote:
>> On Tue, Jun 19, 2018 at 04:35:40PM +0100, Punit Agrawal wrote:
>>> Michal Hocko writes:
>>>
>>>> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
>>
Xie XiuQi writes:
> Hi Lorenzo, Punit,
>
>
> On 2018/6/20 0:32, Lorenzo Pieralisi wrote:
>> On Tue, Jun 19, 2018 at 04:35:40PM +0100, Punit Agrawal wrote:
>>> Michal Hocko writes:
>>>
>>>> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
>>
Michal Hocko writes:
> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
> [...]
>> In terms of $SUBJECT, I wonder if it's worth taking the original patch
>> as a temporary fix (it'll also be easier to backport) while we work on
>> fixing these other issues and enabling me
Michal Hocko writes:
> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
> [...]
>> In terms of $SUBJECT, I wonder if it's worth taking the original patch
>> as a temporary fix (it'll also be easier to backport) while we work on
>> fixing these other issues and enabling me
1 - 100 of 992 matches
Mail list logo
