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
verride 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
eturn 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 appropr
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 freque
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 f
> #address-cells = <2>;
> #size-cells = <2>;
> @@ -384,6 +390,12 @@ spi6: spi@28146000 {
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + wdt:
,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> uart0: serial@2820 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0 0x2820 0 0x1000>;
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
*irq_chip;
> + 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;
>
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
> Documentation/device
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 maintain
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
verride 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
4 are somewhat 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
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
performance domains 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/proce
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 above
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. Curr
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-
>> ker...@vger.kerne
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 that
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 mo
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)
> forma
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: Alexa
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: "
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.
Signed-off-by: Punit Agrawal
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vge
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 larg
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/.ma
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 p
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
000)^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
atches 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
n 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
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 uW/M
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 wrote:
>
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
review tag [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/li
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/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Sha
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/msg663562.html
[1] https://www.spinics.net/lists/kvm/msg171065.html
Punit Agrawal (7):
KVM: arm/arm64: Share common code
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.
>>
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 fol
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 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 the
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 a/drivers/b
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 e
Lorenzo Pieralisi writes:
> On Tue, Jun 19, 2018 at 01:52:16PM +0100, Punit Agrawal wrote:
>> Michal Hocko writes:
>>
>> > On Tue 19-06-18 20:03:07, Xie XiuQi wrote:
>> > [...]
>> >> I tested on a arm board with 128 cores 4 numa nodes, but I set
Michal Hocko writes:
> On Tue 19-06-18 20:03:07, Xie XiuQi wrote:
> [...]
>> I tested on a arm board with 128 cores 4 numa nodes, but I set
>> CONFIG_NR_CPUS=72.
>> Then node 3 is not be created, because node 3 has no memory, and no cpu.
>> But some pci device may related to node 3, which be set
Punit Agrawal writes:
[...]
>
> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
> up returning the original node in the fallback path.
>
> Xie, does the below patch help? I can submit a proper patch if this
> fixes the issue for you.
>
> -- >8
e panic because NUMA node
>> > 3 is not a valid node.
>
> Hmm, but this is not a memory-less node. It sounds like a misconfigured
> kernel to me or the broken initialization. Each CPU should have a
> fallback numa node to be used.
>
>> > I triggered this BUG on arm64 platfor
TSUKADA Koutaro writes:
> On 2018/05/19 2:51, Punit Agrawal wrote:
>> Punit Agrawal writes:
>>
>>> Tsukada-san,
>>>
>>> I am not familiar with memcg so can't comment about whether the patchset
>>> is the right way to solve the prob
Hi Tsukada,
I was staring at memcg code to better understand your changes and had
the below thought.
TSUKADA Koutaro writes:
[...]
> In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
> struct hstate. If it is true, it charges to the memory cgroup to which the
> task that o
Punit Agrawal writes:
> Tsukada-san,
>
> I am not familiar with memcg so can't comment about whether the patchset
> is the right way to solve the problem outlined in the cover letter but
> had a couple of comments about this patch.
>
> TSUKADA Koutaro writ
Tsukada-san,
I am not familiar with memcg so can't comment about whether the patchset
is the right way to solve the problem outlined in the cover letter but
had a couple of comments about this patch.
TSUKADA Koutaro writes:
> The current memcg implementation assumes that the compound page is TH
Suzuki K Poulose writes:
> On 05/14/2018 03:43 PM, Punit Agrawal wrote:
>> KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault
>> handling to add support for PUD hugepages.
>>
>> Addition of pud hugepage support enables additional hugepage
>>
Catalin Marinas writes:
> On Tue, May 01, 2018 at 11:26:59AM +0100, Punit Agrawal wrote:
>> KVM currently supports PMD hugepages at stage 2. Extend the stage 2
>> fault handling to add support for PUD hugepages.
>>
>> Addition of pud hugepage support enables additi
Laurent Dufour writes:
> On 08/05/2018 13:04, Punit Agrawal wrote:
>> Hi Laurent,
>>
>> Laurent Dufour writes:
>>
>>> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT which turns on the
>>> Speculative Page Fault handler when building for 64bit.
>>&g
.
Signed-off-by: Punit Agrawal
Reviewed-by: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 19
arch/arm64/include/asm/kvm_mmu.h | 15 ++
arch/arm64/include/asm/pgtable-hwdef.h | 4
code with arm32.
Signed-off-by: Punit Agrawal
Reviewed-by: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 16
arch/arm64/include/asm/kvm_mmu.h | 10 ++
virt/kvm/arm/mmu.c
.
Signed-off-by: Punit Agrawal
Acked-by: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 5 +
arch/arm64/include/asm/kvm_mmu.h | 5 +
virt/kvm/arm/mmu.c | 7 ---
3 files changed, 14 insertions
erent pagesizes.
Signed-off-by: Punit Agrawal
Reviewed-by: Christoffer Dall
Cc: Marc Zyngier
---
virt/kvm/arm/mmu.c | 69 +++---
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 7f6a944
orrect hunk resulting from a rebase [4/4]
[0] https://www.spinics.net/lists/arm-kernel/msg628053.html
[1] https://lkml.org/lkml/2018/4/20/566
[2] https://lkml.org/lkml/2018/5/1/133
[3] https://lwn.net/Articles/750176/
Punit Agrawal (4):
KVM: arm/arm64: Share common code in user_mem_abort()
KV
Hi Laurent,
Laurent Dufour writes:
> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT which turns on the
> Speculative Page Fault handler when building for 64bit.
>
> Cc: Thomas Gleixner
> Signed-off-by: Laurent Dufour
> ---
> arch/x86/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/
Christoffer Dall writes:
> On Tue, May 01, 2018 at 11:26:56AM +0100, 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 hugepag
Hi Ganesh,
I was looking at evaluating speculative page fault handling on arm64 and
noticed your patch.
Some comments below -
Ganesh Mahendran writes:
> This patch enables the speculative page fault on the arm64
> architecture.
>
> I completed spf porting in 4.9. From the test result,
> we can
Hi Laurent,
One query below -
Laurent Dufour writes:
[...]
>
> Ebizzy:
> ---
> The test is counting the number of records per second it can manage, the
> higher is the best. I run it like this 'ebizzy -mTRp'. To get consistent
> result I repeated the test 100 times and measure the average
Hi Suzuki,
Thanks for having a look.
Suzuki K Poulose writes:
> On 01/05/18 11:26, Punit Agrawal wrote:
>> Introduce helpers to abstract architectural handling of the conversion
>> of pfn to page table entries and marking a PMD page table entry as a
>> block entry.
entries.
Signed-off-by: Punit Agrawal
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 19
arch/arm64/include/asm/kvm_mmu.h | 15 ++
arch/arm64/include/asm/pgtable-hwdef.h | 4
code with arm32.
Signed-off-by: Punit Agrawal
Reviewed-by: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 16
arch/arm64/include/asm/kvm_mmu.h | 10 ++
virt/kvm/arm/mmu.c
.
Signed-off-by: Punit Agrawal
Acked-by: Christoffer Dall
Cc: Marc Zyngier
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm/include/asm/kvm_mmu.h | 5 +
arch/arm64/include/asm/kvm_mmu.h | 5 +
virt/kvm/arm/mmu.c | 7 ---
3 files changed, 14 insertions
erent pagesizes.
Signed-off-by: Punit Agrawal
Reviewed-by: Christoffer Dall
Cc: Marc Zyngier
---
virt/kvm/arm/mmu.c | 66 +++---
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 7f6a944
1 - 100 of 521 matches
Mail list logo
