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

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

On 11/30/21 11:40, Andrea Bolognani wrote:
> 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.
> 
Unfortunately I did. But I think the whole area can be reworked a bit so
that we would detect both arm64 and aarch64 but in a different way than
the original patch.

Michal

On Tue, Nov 30, 2021 at 02:40:07AM -0800, Andrea Bolognani
wrote:
> 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.
We're over thinking things here. The way this change is implemented
is the only way anyone would write this code, and is a simple cut+paste
from the code pattern in the lines above so arguably already a derived
work. This is not a bit of code that meets the criteria to taint you
from a copyright POV.

I just implemented & posted the obvious fix in virArch and it is
identical to the patch referenced earlier in this thread, rather
proving my point.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|