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

[Jag Raman]

On 3/2/2020 11:29 AM, Alex Bennée wrote:
> 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 ;-)

Sorry I didn't realize it's your account. :)

> 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.

We'll run Travis CI also before submitting patches next time. The qemu
wiki page for TravisCI says it tests MacOS. So this test should be
sufficient to cover MacOS build tests I suppose.

https://wiki.qemu.org/Testing/CI/Travis#Testing_Changes_to_Travis

> 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.

We're running these docker tests locally.

Thank you very much!
--
Jag

> 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!