qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH for 2.13 v3 1/2] spapr: Add ibm, max-


From: Serhii Popovych
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH for 2.13 v3 1/2] spapr: Add ibm, max-associativity-domains property
Date: Mon, 16 Apr 2018 19:47:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

Bharata B Rao wrote:
> On Wed, Apr 11, 2018 at 02:41:59PM -0400, Serhii Popovych wrote:
>> Now recent kernels (i.e. since linux-stable commit a346137e9142
>> ("powerpc/numa: Use ibm,max-associativity-domains to discover possible 
>> nodes")
>> support this property to mark initially memory-less NUMA nodes as "possible"
>> to allow further memory hot-add to them.
>>
>> Advertise this property for pSeries machines to let guest kernels detect
>> maximum supported node configuration and benefit from kernel side change
>> when hot-add memory to specific, possibly empty before, NUMA node.
>>
>> Signed-off-by: Serhii Popovych <address@hidden>
>> ---
>>  hw/ppc/spapr.c | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index a81570e..c05bbad 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -910,6 +910,13 @@ static void spapr_dt_rtas(sPAPRMachineState *spapr, 
>> void *fdt)
>>          0, cpu_to_be32(SPAPR_MEMORY_BLOCK_SIZE),
>>          cpu_to_be32(max_cpus / smp_threads),
>>      };
>> +    uint32_t maxdomains[] = {
>> +        cpu_to_be32(4),
>> +        cpu_to_be32(0),
>> +        cpu_to_be32(0),
>> +        cpu_to_be32(0),
>> +        cpu_to_be32(nb_numa_nodes - 1),
>> +    };
>>
>>      _FDT(rtas = fdt_add_subnode(fdt, 0, "rtas"));
>>
>> @@ -946,6 +953,9 @@ static void spapr_dt_rtas(sPAPRMachineState *spapr, void 
>> *fdt)
>>      _FDT(fdt_setprop(fdt, rtas, "ibm,associativity-reference-points",
>>                       refpoints, sizeof(refpoints)));
>>
>> +    _FDT(fdt_setprop(fdt, rtas, "ibm,max-associativity-domains",
>> +                     maxdomains, sizeof(maxdomains)));
>> +
>>      _FDT(fdt_setprop_cell(fdt, rtas, "rtas-error-log-max",
>>                            RTAS_ERROR_LOG_MAX));
>>      _FDT(fdt_setprop_cell(fdt, rtas, "rtas-event-scan-rate",
>> -- 
>> 1.8.3.1
> 
> This commit causes hash guest with latest guest kernel to hang at early boot.

I use v4.16 tag from stable and can't reproduce on P8 machine reported
issue.

Could you please share more details about your setup, kernel commit id
you spot problem?

> 
> Quiescing Open Firmware ...
> Booting Linux via __start() @ 0x0000000002000000 ...
> [    0.000000] hash-mmu: Page sizes from device-tree:
> [    0.000000] hash-mmu: base_shift=12: shift=12, sllp=0x0000, 
> avpnm=0x00000000, tlbiel=1, penc=0
> [    0.000000] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
> avpnm=0x00000000, tlbiel=1, penc=1
> [    0.000000] Using 1TB segments
> [    0.000000] hash-mmu: Initializing hash mmu with SLB
> [    0.000000] Linux version 4.16.0-rc7+ (address@hidden) (gcc version 7.1.1 
> 20170622 (Red Hat 7.1.1-3) (GCC)) #60 SMP Wed Apr 11 10:36:22 IST 2018
> [    0.000000] Found initrd at 0xc000000003c00000:0xc000000004f9a34c
> [    0.000000] Using pSeries machine description
> [    0.000000] bootconsole [udbg0] enabled
> [    0.000000] Partition configured for 32 cpus.
> [    0.000000] CPU maps initialized for 1 thread per core
> [    0.000000] -----------------------------------------------------
> [    0.000000] ppc64_pft_size    = 0x1a
> [    0.000000] phys_mem_size     = 0x200000000
> [    0.000000] dcache_bsize      = 0x80
> [    0.000000] icache_bsize      = 0x80
> [    0.000000] cpu_features      = 0x077c7a6c18500249
> [    0.000000]   possible        = 0xffffffff18500649
> [    0.000000]   always          = 0x0000000018100040
> [    0.000000] cpu_user_features = 0xdc0065c2 0xae000000
> [    0.000000] mmu_features      = 0x78006001
> [    0.000000] firmware_features = 0x00000001415a445f
> [    0.000000] htab_hash_mask    = 0x7ffff
> [    0.000000] -----------------------------------------------------
> 
> No progess after this.
> 
> 


-- 
Thanks,
Serhii

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]