qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 00/50] Initial support for multi-process qemu


From: Alex Bennée
Subject: Re: [PATCH v5 00/50] Initial support for multi-process qemu
Date: Mon, 02 Mar 2020 16:29:36 +0000
User-agent: mu4e 1.3.9; emacs 27.0.90

Jag Raman <address@hidden> writes:

> On 3/1/2020 6:57 AM, Alex Bennée wrote:
>> Jagannathan Raman <address@hidden> writes:
>> 
>>> Hello
>>>    Started with the presentation in October 2017 made by Marc-Andre
>>> (Red Hat)
>>> and Konrad Wilk (Oracle) [1], and continued by Jag's BoF at KVM Forum 2018,
>>> the multi-process project is now available and presented in this patchset.
>>> This first series enables the emulation of lsi53c895a in a separate process.
>>>
>>> We posted the Proof Of Concept patches [2] before the BoF session in 2018.
>>> Subsequently, we posted RFC v1 [3], RFC v2 [4], RFC v3 [5] and RFC v4 [6].
>>>
>>> John & Elena presented the status of this project in KVM Forum 2019. We
>>> appreciate the in-person and email feedback we received to improve this
>>> patchset. We also received valuable feedback and direction on future
>>> improvements from the bi-weekly KVM community conference. We have
>>> incorporated all the feedback in the current version of the series, v5.
>>>
>>> Following people contributed to this patchset:
>>>
>>> John G Johnson <address@hidden>
>>> Jagannathan Raman <address@hidden>
>>> Elena Ufimtseva <address@hidden>
>>> Kanth Ghatraju <address@hidden>
>>> Konrad Wilk <address@hidden>
>>>
>>> For full concept writeup about QEMU disaggregation, refer to
>>> docs/devel/qemu-multiprocess.rst. Please refer to
>>> docs/qemu-multiprocess.txt for usage information.
>>>
>>> We are planning on making the following improvements in the future to the 
>>> experimental
>>> Qemu multi-process:
>>>   - Asynchronous communication channel;
>>>   - Performance improvements;
>>>   - Libvirt support;
>>>   - Enforcement of security policies and privileges control;
>>>
>>> We welcome all your ideas, concerns, and questions for this patchset.
>> There seem to be quite a few CI failures with this series applied:
>>    https://travis-ci.org/stsquad/qemu/builds/656432858
>>    https://app.shippable.com/github/stsquad/qemu/runs/1275/summary/console
>>    https://gitlab.com/stsquad/qemu/pipelines/122030403
>>    https://cirrus-ci.com/build/4577637150490624
>
> Hi Alex,
>
> Thanks for pointing it out.
>
> "Patchew" also identified some errors which we are working on fixing for
> the next version. Patchew summarized the errors in the following page:
> https://patchew.org/QEMU/address@hidden/
>
> To confirm we're compliant with Patchew, we are running docker tests
> before sending the patches for review next time around.
>
> We'll use the following wiki to trigger "travis-ci" tests before pushing
> the branch for review next time around:
> https://wiki.qemu.org/Testing/CI/Travis#Testing_Changes_to_Travis
>
> Are shippable, stsquad & cirrus-ci redundant if travis-ci & docker
> tests

stsquad is just my user account, hopefully I'm not redundant ;-)

They all test slightly different things but you should be able to
replicate the tests locally.

Travis basically tests a bunch of different configuration setups on
mostly x86 hardware. Unless it's a weird library interaction issue this
should replicate in your normal build environment.

Shippable are cross compile tests. They use the existing docker
infrastructure to cross compile for various target architectures. See
"make docker" and the notes in docs/devel/testing.rst.

CirrusCI tests MacOS and FreeBSD builds. You can build on the BSD's
yourself, see "make vm-help". MacOSX is trickier unless you have a Mac
yourself of course.

> pass?
>
> Thank you very much!


-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]