On Wed, Jun 4, 2025 at 3:51 AM Alexandr Moshkov <dtalexund...@yandex-team.ru> wrote: > > > On 5/29/25 01:12, Thomas Huth wrote: > > On 28/05/2025 21.23, Stefan Hajnoczi wrote: > >> On Wed, May 28, 2025 at 6:12 AM Thomas Huth <th...@redhat.com> wrote: > >>> > >>> Hi! > >>> > >>> The following changes since commit > >>> 80db93b2b88f9b3ed8927ae7ac74ca30e643a83e: > >>> > >>> Merge tag 'pull-aspeed-20250526' of > >>> https://github.com/legoater/qemu into staging (2025-05-26 10:16:59 > >>> -0400) > >>> > >>> are available in the Git repository at: > >>> > >>> https://gitlab.com/thuth/qemu.git tags/pull-request-2025-05-28 > >>> > >>> for you to fetch changes up to > >>> 9c2da02e184fddfa7cd7d7813455c2306daae99a: > >>> > >>> tests/unit/test-util-sockets: fix mem-leak on error object > >>> (2025-05-28 11:59:47 +0200) > >>> > >>> ---------------------------------------------------------------- > >>> * Functional tests improvements > >>> * Endianness improvements/clean-ups for the Microblaze machines > >>> * Remove obsolete -2.4 and -2.5 i440fx and q35 machine types and > >>> related code > >>> > >>> ---------------------------------------------------------------- > >>> Alexandr Moshkov (2): > >>> tests/functional: add skipLockedMemoryTest decorator > >>> tests/functional: add memlock tests > >> > >> Hi Thomas and Alexandr, > >> The memlock tests are failing: > >> https://gitlab.com/qemu-project/qemu/-/jobs/10181084830#L5421 > >> https://gitlab.com/qemu-project/qemu/-/jobs/10181084865#L5476 > >> > >> Please take a look and send a new pull request. Thanks! > > > Hello! I think Stefan forgot to CC me in his reply. Only now find this > message) > > > > According to the log: > > > > Output: qemu-system-aarch64: No machine specified, and there is no > > default > > > > I think it likely does not make sense to run this test with the > > aarch64 target... Alexandr, would it make sense to limit this to x86 > > only? > > It looks like adding this lines to vm creation fixes all problems with > other targets on memlock test: > > self.set_machine('none') > self.vm.add_args('-nodefaults') > > What's the convenient way to fix it? Resend a new patch?
Hi Alexandr, Sorry I forgot to CC you. Since the patch in question hasn't been merged yet, you could send a new revision of the patch and Thomas could include it in his next pull request. That way the fixed patch will be introduced in one commit rather than a broken commit followed by a fix. Stefan > > > Best regards, > > Alexandr >
