libvirt users - Nov 2021 - virsh create fails with "Unable to find any firmware to satisfy 'efi'" for aarch64 guest on macOS

On 11/30/21 06:49, Nathan Vander Wilt wrote:
> On Mon, Nov 29, 2021 at 2:28 AM J?n Tomko <jtomko at redhat.com>
wrote:
>> Can you try with the latest libvirt?
>> 7.10.0-rc2 was just tagged today and should be out this week:
>>
https://listman.redhat.com/archives/libvirt-announce/2021-November/msg00002.html
> 
> Ah, but it looks like the arm64 -> VIR_ARCH_AARCH64 patch
>
(https://github.com/ihsakashi/libvirt/commit/0f062221ae23e6ea0ed5e6ba65d47395581cb143.patch)
> is still in limbo? AFAICT that's the main issue I'm hitting now.
Looking into virArchFromHost() I can see uname() called which is then
passed to virArchFromString(). In here, uname machine (which is
equivalent to 'uname -m' from shell) is compared against virArchData
array:

https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virarch.c#L42

So what you are saying is that 'uname -m' reports arm64 and not aarch64?
If that's the case then we should revisit the patch you mention.
> 
>> Andrea did some fixes that are supposed to help with Apple Silicon:
>> https://gitlab.com/libvirt/libvirt/-/issues/168
> 
> Yes, I happened to find that thread a little while after posting here
> and it has lots of tips but didn't directly address my confusion
> regarding how to manually specify the files. But based on the
> "internal error: undefined hardware architecture" I'm now
getting I
> think I will need some of the patches.
> 
> For now I've just wrestled through direct usage of QEMU from the
> command line as ironically this whole exercise was to try keeping
> random build chains off my main "shiny new" macOS install itself.
> Thanks for the pointers and glad these issues are gradually getting
> worked out. I think I just must still be in the early adopters on the
> M1 platform and hit some growing pains!
Yeah, unfortunately I don't have access to M1 yet so all I can give is
suggestions.

Michal

On Tue, Nov 30, 2021 at 09:54:38AM +0100, Michal Pr?vozn?k
wrote:
> On 11/30/21 06:49, Nathan Vander Wilt wrote:
> > Ah, but it looks like the arm64 -> VIR_ARCH_AARCH64 patch
> > is still in limbo? AFAICT that's the main issue I'm hitting
now.
Unfortunately that's the case.
> Looking into virArchFromHost() I can see uname() called which is then
> passed to virArchFromString(). In here, uname machine (which is
> equivalent to 'uname -m' from shell) is compared against
virArchData array:
>
> https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virarch.c#L42
>
> So what you are saying is that 'uname -m' reports arm64 and not
aarch64?
> If that's the case then we should revisit the patch you mention.
Correct: on Apple Silicon Macs the architecture name is reported as
"arm64", but our code expects it to be "aarch64" because
that's what
we get on Linux.

Michal, have you actually looked at the patch mentioned earlier? If
not, you can perhaps do a clean room implementation of the fix based
on the information provided above and get us out of this stalemate?

It's quite a simple change, but having seen the original patch I feel
like I couldn't possibly submit it myself and still be in the clear.

-- 
Andrea Bolognani / Red Hat / Virtualization