> On Wed, Apr 27, 2016 at 05:04:38PM +0100, Gordan Bobic wrote:
>> >
>> >Maybe that's something that CentOS have added (don't know, haven't
>> >looked), RHELSA doesn't support it that I'm aware of and they're
>> >definitely only 64K page size. The biggest change is in rpm and the
>> >arch mappings there.
>> They might not support it, but it most certainly works. There are no
>> changes specific to this that I can find in CentOS. All I changed was
>> rebuilt the host kernel with 4KB pages and ARM32 support (still an
>> aarch64 kernel). C7 armv7hl guest is completely unmodified apart from
>> the /etc/rpm/platform being set explicitly.
>>
>> The main point being that the original assertion that making this
>> work would require rpm, yum, packagekit, mock and other code changes
>> doesn't seem to be correct based on empirical evidence.
>>
>
> It may work with rpm, but, as per the original post, dnf does not
> support it, and dnf should not support it as long as Fedora
> does not support a 32 bit userspace on aarch64.
That sounds an awful lot like trying to justify what is arguably
a bug in dnf, specifically, that unlike yum that it is replacing,
it ignores /etc/rpm/platform.
>> Despite Linus' words of wisdom to the contrary over the years. :-(
>>
>
> Linus is not God, and we'd rather support as broad as possible a
> range of hardware.
1) He is not God, but he is smarter and better informed than
most on the subject at hand. Can you link to an overwhelming
counter-argument from someone even remotely similarly qualified?
2) Nobody has yet pointed at ARM's own documentation (I did ask
earlier) that says that 4KB memory page support is optional
rather than mandatory.
The closest I can find on this from ARM are the following:
http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/ch12s04.html
https://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf
https://www.arm.com/files/downloads/ARMv8_Architecture.pdf
and all of the above list that ARMv8 should support both 4KB
and 64KB memory pages.
And if 4KB support is in fact mandatory, then arguably the
decision to opt for 64KB for the sake of supporting Seattle was
based on wanting to support broken hardware that turned out to
be too little too late anyway.
>> >Yes, because the instructions can be dealt with by the hypervisor
>> >whether through emulation, or some other mechanism.
>>
>> If it's going to run in emulation you might as well run it on
>> some highest end possible x86 hardware, it'll be slightly less
>> excruciatingly slow. And last I checked, that still had issues
>> with availability of kernels and architectures emulated.
>
> Actually, with kvm, you get pretty much the same speed as native
> aarch64 vms.
Running armv7hl VMs on ARMv8 hardware without ARM32 support?
(Ignoring for the moment the fact that even when running
the same guest and host architectures in a VM comes with a
much greater impact than "pretty much the same speed as native".)
> Also, server grade aarch64 h/w will give you
> pretty decent performance. I'm less sure about SBCs; they're
> dependent on the SoC used.
I am quite aware. I am very pleased with my Gigabyte MP30-AR0
with an X-Gene and 128GB of RAM. But that I can buy off the
shelf right now, whereas standard form factor Seattles that
were promised a couple of years ago are still nowhere to be
seen (what I was referring to by too little too late above).
> On the whole, 32 bit arm vms are going to have the same
> performance on aarch64 as i686 on x86_64.
Are you saying that on hardware that is lacking the optional
ARM32 support a VM running ARM32 binaries is going to run with
approximately same performance as if it were running an
aarch64 OS? If so, how? I am specifically interested because
a part of this debate is hinging on the statement that 32-bit
guests are only supported in VMs rather than chroots because
on ARMv8 32-bit support is optional, but it is not at all
clear or demonstrated that running a 32-bit ARM guest on ARMv8
without 32-bit native support will not suffer the same hit as
running it in QEMU emulation on any other CPU architecture.
So either something magical happens that means that the
missing 32-bit support doesn't have to be fully emulated in
software, or the entire argument being made for VMs instead
of chroots is entirely erroneous.
Gordan
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
No comments:
Post a Comment