[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 00/20] Migration 20230420 patches
From: |
Juan Quintela |
Subject: |
Re: [PULL 00/20] Migration 20230420 patches |
Date: |
Mon, 24 Apr 2023 11:57:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Juan Quintela <quintela@redhat.com> wrote:
> Richard Henderson <richard.henderson@linaro.org> wrote:
>> On 4/22/23 10:21, Juan Quintela wrote:
>>> Richard Henderson <richard.henderson@linaro.org> wrote:
>>>> On 4/20/23 14:17, Juan Quintela wrote:
>> I'll note that mips32 and armv6 (that is, *not* debian's armv7 based
>> armhf distro) are the only hosts we have that don't have an atomic
>> 8-byte operation.
>
> This is the kind of trouble that I don'k now what to do. I am pretty
> sure that nobody is goigng to migrate a host that has so much RAM than
> needs a 64bit counter in that two architectures (or any 32 architectures
> for what is worth).
>
> A couple of minutes after sending the 1st email, I considederd sending
> another one saying "my toolchain lies better than yours".
>
> I moved the atomic operations that do the buildcheck and run make again:
>
> $ rm -f qemu-system-mips*
> $ time make
>
> [....]
>
> [2/5] Linking target qemu-system-mipsel
> [3/5] Linking target qemu-system-mips
> [4/5] Linking target qemu-system-mips64el
> [5/5] Linking target qemu-system-mips64
>
> So clearly my toolchain is lying O:-)
And here I am.
Wearing a brow paper bag on my head for week.
These are emulatores for mips. Not cross-compiled to run on MIPS.
/me hides on the hills in shame.
Later, Juan.
- [PULL 20/20] migration: Pass migrate_caps_check() the old and new caps, (continued)
- [PULL 20/20] migration: Pass migrate_caps_check() the old and new caps, Juan Quintela, 2023/04/20
- [PULL 02/20] postcopy-ram: do not use qatomic_mb_read, Juan Quintela, 2023/04/20
- [PULL 14/20] migration: Rename normal to normal_pages, Juan Quintela, 2023/04/20
- [PULL 10/20] migration: Make postcopy_requests atomic, Juan Quintela, 2023/04/20
- [PULL 15/20] migration: Handle block device inactivation failures better, Juan Quintela, 2023/04/20
- Re: [PULL 00/20] Migration 20230420 patches, Richard Henderson, 2023/04/22