On 10/10/19 12:01, Michael S. Tsirkin wrote: > On Tue, Oct 08, 2019 at 05:59:31PM +0200, Igor Mammedov wrote:
>> So far there were no need for it as all possible cpus are >> described in ACPI tables passed to guest, but I'm not going >> to suggest to parse them on firmware side as it's too complicated :) > > We can always add a QEMU specific data table by the way. > Format would be up to us and would be easy to parse. > I don't see a big advantage as compared to fw cfg though. I'd like to comment just on this part. *If* we decide to expose the information through some kind of data table (as opposed to the modern CPU hotplug register block), then the representation *must* be a dedicated fw_cfg blob. It cannot be an ACPI table. The reason is that *selecting* the fw_cfg blob that contains the ACPI linker/loader script is a very specific action (it re-generates the ACPI payload, with dependencies on assigned PCI resources). Therefore, it is done in a super-particular spot in the firmware. On the other hand, the "possible CPUs count" is needed much earlier than that. I need to fetch that info way before PCI resource assignment appears on the radar. So please let us stick with "ACPI is only for the guest OS to read" rule -- it's not only a parsing convenience for the firmware, but a real necessity. Thanks Laszlo
