linux-kernel - RE: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0ff033fa8eac400fade06e6be0a98847@huawei.com>
Date:   Tue, 18 May 2021 18:50:46 +0000
From:   Salil Mehta <salil.mehta@...wei.com>
To:     Andrew Jones <drjones@...hat.com>
CC:     "wangyanan (Y)" <wangyanan55@...wei.com>,
        Peter Maydell <peter.maydell@...aro.org>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        "Igor Mammedov" <imammedo@...hat.com>,
        Shannon Zhao <shannon.zhaosl@...il.com>,
        Alistair Francis <alistair.francis@....com>,
        David Gibson <david@...son.dropbear.id.au>,
        "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
        "qemu-arm@...gnu.org" <qemu-arm@...gnu.org>,
        "Paolo Bonzini" <pbonzini@...hat.com>,
        Philippe Mathieu-Daudé <philmd@...hat.com>,
        yangyicong <yangyicong@...wei.com>,
        "Zengtao (B)" <prime.zeng@...ilicon.com>,
        "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
        "Wanghaibin (D)" <wanghaibin.wang@...wei.com>,
        zhukeqian <zhukeqian1@...wei.com>,
        yuzenghui <yuzenghui@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxarm@...neuler.org" <linuxarm@...neuler.org>
Subject: RE: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu
 members

> From: Andrew Jones [mailto:drjones@...hat.com]
> Sent: Tuesday, May 18, 2021 8:50 AM
> 
> On Tue, May 18, 2021 at 07:04:51AM +0000, Salil Mehta wrote:
> > > From: wangyanan (Y)
> > > Sent: Tuesday, May 18, 2021 5:43 AM
> > >
> > > Hi Salil,
> > >
> > > On 2021/5/18 4:48, Salil Mehta wrote:
> > > >> From: Qemu-arm
> > > [mailto:qemu-arm-bounces+salil.mehta=huawei.com@...gnu.org]
> > > >> On Behalf Of Yanan Wang
> > > >> Sent: Sunday, May 16, 2021 11:29 AM
> > > >> To: Peter Maydell <peter.maydell@...aro.org>; Andrew Jones
> > > >> <drjones@...hat.com>; Michael S . Tsirkin <mst@...hat.com>; Igor Mammedov
> > > >> <imammedo@...hat.com>; Shannon Zhao <shannon.zhaosl@...il.com>; Alistair
> > > >> Francis <alistair.francis@....com>; David Gibson
> > > >> <david@...son.dropbear.id.au>; qemu-devel@...gnu.org;
> qemu-arm@...gnu.org
> > > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>; zhukeqian
> > > >> <zhukeqian1@...wei.com>; yangyicong <yangyicong@...wei.com>; Zengtao (B)
> > > >> <prime.zeng@...ilicon.com>; Wanghaibin (D)
> <wanghaibin.wang@...wei.com>;
> > > >> yuzenghui <yuzenghui@...wei.com>; Paolo Bonzini <pbonzini@...hat.com>;
> > > >> Philippe Mathieu-Daudé <philmd@...hat.com>
> > > >> Subject: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members
> > > >>
> > > >> We create and initialize a cpuobj for each present cpu in
> > > >> machvirt_init(). Now we also initialize the cpu member of
> > > >> structure CPUArchId for each present cpu in the function.
> > > > [...]
> > > >
> > > >>           qdev_realize(DEVICE(cpuobj), NULL, &error_fatal);
> > > >> +
> > > >> +        /*
> > > >> +         * As ARM cpu hotplug is not supported yet, we initialize
> > > >> +         * the present cpu members here.
> > > >> +         */
> > > >> +        machine->possible_cpus->cpus[n].cpu = cpuobj;
> > > >
> > > > when vcpu Hotplug is not supported yet, what necessitates this change now?
> > > >
> > > The initialization will gives a way to determine whether a CPU is
> > > present or not.
> > > At least, for now it will be used when generating ACPI tables, e.g.
> > > DSDT, MADT.
> > > See patch 5 and 6.
> >
> > yes,  but why do you require it now as part of the vcpu topology change?
> >
> > As-far-as-i-can-see, PPTT table changes(part of patch 5/9) do not require
> > this change. Change in Patch 5/9 has also been done in anticipation of
> > some future requirement(vcpu Hotplug?).
> >
> > Please correct me here if I am wrong?
> >
> 
> Hi Salil,
> 
> The problem is that we've never required smp.cpus == smp.maxcpus, so
> a user could have smp.cpus < smp.maxcpus. We want the topology to match
> maxcpus, but only enable cpus. However, if you think we should just not
> allow cpus < maxcpus until hot plug is sorted out, then we could discuss
> a way of trying to enforce cpus == maxcpus, but I'm not sure how we can
> without breaking existing command lines.


Hi Andrew,
Ideally, if the vcpu Hotplug is not supported the check in the smp_parse()
should impose (cpus == maxcpus). This as of now is just a warning of invalid
configuration I think. Beside this does not breaks any prior usages which you
suggested might happen?

Again, this is not a blocking issue from my side but just a humble suggestion.
You might want to take a call on this :)


Thanks
Salil.