On Thu, 10 Oct 2019 05:56:55 -0400 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote: > > As an alternative to passing to firmware topology info via new fwcfg files > > so it could recreate APIC IDs based on it and order CPUs are enumerated, > > > > extend CPU hotplug interface to return APIC ID as response to the new > > command > > CPHP_GET_CPU_ID_CMD. > > One big piece missing here is motivation: I thought the only willing reader was Laszlo (who is aware of context) so I skipped on details and confused others :/ > Who's going to use this interface? In current state it's for firmware, since ACPI tables can cheat by having APIC IDs statically built in. If we were creating CPU objects in ACPI dynamically we would be using this command as well. It would save us quite a bit space in ACPI blob but it would be a pain to debug and diagnose problems in ACPI tables, so I'd rather stay with static CPU descriptions in ACPI tables for the sake of maintenance. > So far CPU hotplug was used by the ACPI, so we didn't > really commit to a fixed interface too strongly. > > Is this a replacement to Laszlo's fw cfg interface? > If yes is the idea that OVMF going to depend on CPU hotplug directly then? > It does not depend on it now, does it? It doesn't, but then it doesn't support cpu hotplug, OVMF(SMM) needs to cooperate with QEMU "and" ACPI tables to perform the task and using the same interface/code path between all involved parties makes the task easier with the least amount of duplicated interfaces and more robust. Re-implementing alternative interface for firmware (fwcfg or what not) would work as well, but it's only question of time when ACPI and this new interface disagree on how world works and process falls apart. > If answers to all of the above is yes, then I don't really like it: it > is better to keep all paravirt stuff in one place, namely in fw cfg. Lets discuss, what cpu hotplug fwcfg interface could look like in [PATCH 3/4] hw/i386: add facility to expose CPU topology over fw-cfg mail thread and clarify (dis)likes with concrete reasons. So far I managed to convince myself that we ought to reuse and extend current CPU hotplug interface with firmware features, to endup with consolidated cpu hotplug process without introducing duplicate ABIs, but I could be wrong so lets see if fwcfg will be the better approach. > > CC: Laszlo Ersek <ler...@redhat.com> > > CC: Eduardo Habkost <ehabk...@redhat.com> > > CC: "Michael S. Tsirkin" <m...@redhat.com> > > CC: Gerd Hoffmann <kra...@redhat.com> > > CC: Paolo Bonzini <pbonz...@redhat.com> > > CC: Philippe Mathieu-Daudé <phi...@redhat.com> > > CC: Richard Henderson <r...@twiddle.net> > > > > Igor Mammedov (3): > > acpi: cpuhp: fix 'Command data' description is spec > > acpi: cpuhp: add typical usecases into spec > > acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command > > > > docs/specs/acpi_cpu_hotplug.txt | 37 ++++++++++++++++++++++++++++++--- > > hw/acpi/cpu.c | 15 +++++++++++++ > > hw/acpi/trace-events | 1 + > > 3 files changed, 50 insertions(+), 3 deletions(-) > > > > -- > > 2.18.1 >