On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
On Wed, Nov 12, 2014 at 09:08:55AM +0000, Claudio Fontana wrote:
On 11.11.2014 16:29, Mark Rutland wrote:
I tend to mostly agree with this, we might look for alternative solutions for speeding up guest startup in the future but in general if getting ACPI in the guest for ARM64 requires also getting UEFI, then I can personally live with that, especially if we strive to have the kind of optimized virtualized UEFI you mention.
Given that UEFI will be required for other guests (e.g. if you want to boot a distribution's ISO image), I hope that virtualised UEFI will see some optimisation work.
I think the requirement it just for KVM to provide something that behaves exactly like UEFI, it doesn't have to be the full Tianocore implementation if it's easier to reimplement the boot interface.
We already have a port of Tinaocode that works for virt, but yes, implementing something ligther is certainly possible.
As mentioned by others, I'd rather see an implementation of ACPI in QEMU which learns from the experience of X86 (and possibly shares some code if possible), rather than going in a different direction by creating device trees first, and then converting them to ACPI tables somewhere in the firmware, just because device trees are "already there", for the reasons which have already been mentioned before by Igor and others.
For the features which ACPI provides which device trees do not (e.g. the dynamic addition and removal of memory and CPUs), there will need to be some sort of interface between QEMU and the ACPI implementation. That's already outside of the realm of DT, so as previously mentioned a simple conversion doesn't cover the general case.
I think we need to support the low-level interfaces in the kernel for this anyway, we should not have to use ACPI just to do memory and CPU hotplugging in KVM, that would be silly.
I had that same intuitive feeling, but lacked good tecnical arguments for it. Care to elaborate on that?
If ACPI is present, it can provide a wrapper for the same interface, but KVM should not need to be aware of the fact that ACPI is used in the guest, after it has passed the initial ACPI blob to the kernel.
That's where things begin to be a bit foggy for me. AFAIU ACPI already has a method for doing this and I speculate that there is some IRQ assigned to an ACPI event that causes some AML code to be interpreted by your OS. Wouldn't it be a matter of QEMU putting the right AML table fragments in place to wire this up then?
-Christoffer