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
