From andreea.florescu15 at gmail.com  Tue Jul  5 13:37:31 2022
From: andreea.florescu15 at gmail.com (Andreea Florescu)
Date: Tue, 5 Jul 2022 16:37:31 +0300
Subject: [Rust-VMM] Licensing Issue in rust-vmm crates
In-Reply-To: <CAKcU8Z3MrsWEb6ocgNhn8P_Dh-dh3xYSH5=-tPRGLPa9Qaqq3A@mail.gmail.com>
References: <CAKcU8Z3ks8mPS-G4ivc5aqAPCp-=uRRLqXAAB9GdAwY93Eo2mA@mail.gmail.com>
 <CABgObfYmivrMbMuHmSzkm8Kp+aqwpAd+P1gvdXK51=aO0DUoXg@mail.gmail.com>
 <CAELaAXzhpm=C_fu8AENnWuBkGnMXXEOeDyK6qTndUjZih8D_Cg@mail.gmail.com>
 <20220622224729.kf7xvrky4f7hs4an@yuggoth.org>
 <CAKcU8Z3MrsWEb6ocgNhn8P_Dh-dh3xYSH5=-tPRGLPa9Qaqq3A@mail.gmail.com>
Message-ID: <CAKcU8Z3brMrY7V8EV9U1Dt2+Ebx-CGnCTVUf7h3DT+f5npLpAw@mail.gmail.com>

Gerry, Rob, Sebastien, what do you think about this?
I would like to go ahead with the license change to Apache 2.0 OR
BSD-3-Clause and it would be great to also get an ACK from you.

Thanks,
Andreea

On Thu, Jun 30, 2022 at 10:01 AM Andreea Florescu <
andreea.florescu15 at gmail.com> wrote:

> I just wanted to clarify something as well, I do not feel strongly about
> changing the license to BSD-3-Clause, we can also use Apache 2.0 OR
> BSD-3-Clause if that makes sense. My interest is to fix the problem
> initially reported which significantly limits the usefulness of this
> project as it cannot be used by projects like QEMU.
> As most contributions are coming from Google (indirectly), Amazon, Intel
> and Alibaba, it would be really helpful to also get input on updating the
> license from the folks that are contributing from the respective companies.
> From the Amazon side of things, we discussed this internally and we're
> onboard with the change.
>
> Thanks,
> Andreea
>
> On Thu, Jun 23, 2022 at 1:48 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
>> On 2022-06-22 17:30:37 +0100 (+0100), Alberto Faria wrote:
>> [...]
>> > I may be misunderstanding this, but it sounds like you're assuming
>> > that Apache-2.0 is a superset of BSD-3-clause in terms of user
>> > obligations. I have no idea if this is actually the case or not, but
>> > if it is, then "Apache-2.0 OR BSD-3-clause" == "BSD-3-clause", which
>> > in a sense contradicts the wide use of the former in Rust crates.
>> [...]
>>
>> I'm not a lawyer, but my long-time understanding has been that when
>> you distribute software under "license x or license y" that allows
>> people who are receiving and possibly redistributing and deriving
>> that software to do so based on their choice of either license.
>> Blanket statements like this are rarely helpful however when the
>> software consists of parts under different licenses, such as
>> shipping some files under BSD-3-clause and other files under
>> Apache-2.0 as part of the same project. Under those circumstances,
>> the sum total of the software is effectively held to the union of
>> the requirements for both licenses, but for permissive-style
>> licenses like these it's also not expected that the licenses of some
>> files impact the licenses of the other files, so long as the chosen
>> licenses have compatible terms (permissive-style licenses do not
>> require you to distribute derivative works under the same terms).
>>
>> The situation changes dramatically when copyleft-style licenses are
>> involved, since they often (as is the case with GPL for example)
>> convey transitive requirements which forbid additional licensing
>> requirements on the complete work and require redistribution under
>> the same license instead.
>>
>> As for whether Apache-2.0 is a superset of BSD-3-clause, that's
>> implied by its ancestry, since the original Apache license was
>> effectively a direct copy of BSD-4-clause, and then for Apache-1.1
>> the authors dropped the advertising clause that Berkeley had also
>> dropped, making it then equivalent to BSD-3-clause. Apache-2.0 is a
>> superset of the requirements of Apache-1.1 (and so BSD-3-clause) as
>> it merely adds a grant of patent license to the original terms.
>> --
>> Jeremy Stanley
>> _______________________________________________
>> Rust-vmm mailing list
>> Rust-vmm at lists.opendev.org
>> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220705/f4504bdf/attachment.htm>

From liuj97 at gmail.com  Tue Jul  5 13:39:08 2022
From: liuj97 at gmail.com (Gerry)
Date: Tue, 5 Jul 2022 21:39:08 +0800
Subject: [Rust-VMM] Licensing Issue in rust-vmm crates
In-Reply-To: <CAKcU8Z3brMrY7V8EV9U1Dt2+Ebx-CGnCTVUf7h3DT+f5npLpAw@mail.gmail.com>
References: <CAKcU8Z3ks8mPS-G4ivc5aqAPCp-=uRRLqXAAB9GdAwY93Eo2mA@mail.gmail.com>
 <CABgObfYmivrMbMuHmSzkm8Kp+aqwpAd+P1gvdXK51=aO0DUoXg@mail.gmail.com>
 <CAELaAXzhpm=C_fu8AENnWuBkGnMXXEOeDyK6qTndUjZih8D_Cg@mail.gmail.com>
 <20220622224729.kf7xvrky4f7hs4an@yuggoth.org>
 <CAKcU8Z3MrsWEb6ocgNhn8P_Dh-dh3xYSH5=-tPRGLPa9Qaqq3A@mail.gmail.com>
 <CAKcU8Z3brMrY7V8EV9U1Dt2+Ebx-CGnCTVUf7h3DT+f5npLpAw@mail.gmail.com>
Message-ID: <F94E213E-D129-466A-A7C8-7604F54EB11E@linux.alibaba.com>

I?m OK with changing the license, otherwise qemu can?t make use of the rust-vmm components.

> 2022?7?5? ??9:37?Andreea Florescu <andreea.florescu15 at gmail.com <mailto:andreea.florescu15 at gmail.com>> ???
> 
> Gerry, Rob, Sebastien, what do you think about this?
> I would like to go ahead with the license change to Apache 2.0 OR BSD-3-Clause and it would be great to also get an ACK from you.
> 
> Thanks,
> Andreea
> 
> On Thu, Jun 30, 2022 at 10:01 AM Andreea Florescu <andreea.florescu15 at gmail.com <mailto:andreea.florescu15 at gmail.com>> wrote:
> I just wanted to clarify something as well, I do not feel strongly about changing the license to BSD-3-Clause, we can also use Apache 2.0 OR BSD-3-Clause if that makes sense. My interest is to fix the problem initially reported which significantly limits the usefulness of this project as it cannot be used by projects like QEMU.
> As most contributions are coming from Google (indirectly), Amazon, Intel and Alibaba, it would be really helpful to also get input on updating the license from the folks that are contributing from the respective companies. From the Amazon side of things, we discussed this internally and we're onboard with the change.
> 
> Thanks,
> Andreea
> 
> On Thu, Jun 23, 2022 at 1:48 AM Jeremy Stanley <fungi at yuggoth.org <mailto:fungi at yuggoth.org>> wrote:
> On 2022-06-22 17:30:37 +0100 (+0100), Alberto Faria wrote:
> [...]
> > I may be misunderstanding this, but it sounds like you're assuming
> > that Apache-2.0 is a superset of BSD-3-clause in terms of user
> > obligations. I have no idea if this is actually the case or not, but
> > if it is, then "Apache-2.0 OR BSD-3-clause" == "BSD-3-clause", which
> > in a sense contradicts the wide use of the former in Rust crates.
> [...]
> 
> I'm not a lawyer, but my long-time understanding has been that when
> you distribute software under "license x or license y" that allows
> people who are receiving and possibly redistributing and deriving
> that software to do so based on their choice of either license.
> Blanket statements like this are rarely helpful however when the
> software consists of parts under different licenses, such as
> shipping some files under BSD-3-clause and other files under
> Apache-2.0 as part of the same project. Under those circumstances,
> the sum total of the software is effectively held to the union of
> the requirements for both licenses, but for permissive-style
> licenses like these it's also not expected that the licenses of some
> files impact the licenses of the other files, so long as the chosen
> licenses have compatible terms (permissive-style licenses do not
> require you to distribute derivative works under the same terms).
> 
> The situation changes dramatically when copyleft-style licenses are
> involved, since they often (as is the case with GPL for example)
> convey transitive requirements which forbid additional licensing
> requirements on the complete work and require redistribution under
> the same license instead.
> 
> As for whether Apache-2.0 is a superset of BSD-3-clause, that's
> implied by its ancestry, since the original Apache license was
> effectively a direct copy of BSD-4-clause, and then for Apache-1.1
> the authors dropped the advertising clause that Berkeley had also
> dropped, making it then equivalent to BSD-3-clause. Apache-2.0 is a
> superset of the requirements of Apache-1.1 (and so BSD-3-clause) as
> it merely adds a grant of patent license to the original terms.
> -- 
> Jeremy Stanley
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org <mailto:Rust-vmm at lists.opendev.org>
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm <http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220705/95d6be7f/attachment.htm>

From kennelson11 at gmail.com  Tue Jul  5 20:46:43 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 5 Jul 2022 15:46:43 -0500
Subject: [Rust-VMM] Fwd: October 2022 PTG Dates & Registration
In-Reply-To: <CAJ6yrQhNYUqaa5tBDAi0rNnv4dvbLf+HmPHxpd44fREUhmLiQA@mail.gmail.com>
References: <CAJ6yrQhNYUqaa5tBDAi0rNnv4dvbLf+HmPHxpd44fREUhmLiQA@mail.gmail.com>
Message-ID: <CAJ6yrQgwYHAq6Own+gOPA6gvWxoZkZx2eL+7TDoC6k_yv7RWUA@mail.gmail.com>

Hello Everyone!

As you may have seen, we announced the next PTG[1] which will take place
October 17-20, 2022 in Columbus, Ohio!

Registration is now open[2].

We have also secured a limited, discounted hotel block for PTG attendees
[3].

If your organization is interested in sponsoring the event, information on
packages and pricing are now available on the PTG website [1] or feel free
to reach out directly to ptg at openinfra.dev.

Can't wait to SEE you all there!

-Kendall Nelson (diablo_rojo)

[1] https://openinfra.dev/ptg/
[2] https://openinfra-ptg.eventbrite.com/
[3] https://www.hyatt.com/en-US/group-booking/CMHRC/G-L0RT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220705/f754c9c7/attachment-0001.htm>

From robert.bradford at intel.com  Wed Jul  6 16:54:17 2022
From: robert.bradford at intel.com (Bradford, Robert)
Date: Wed, 6 Jul 2022 16:54:17 +0000
Subject: [Rust-VMM] Licensing Issue in rust-vmm crates
In-Reply-To: <CAKcU8Z3brMrY7V8EV9U1Dt2+Ebx-CGnCTVUf7h3DT+f5npLpAw@mail.gmail.com>
References: <CAKcU8Z3ks8mPS-G4ivc5aqAPCp-=uRRLqXAAB9GdAwY93Eo2mA@mail.gmail.com>
 <CABgObfYmivrMbMuHmSzkm8Kp+aqwpAd+P1gvdXK51=aO0DUoXg@mail.gmail.com>
 <CAELaAXzhpm=C_fu8AENnWuBkGnMXXEOeDyK6qTndUjZih8D_Cg@mail.gmail.com>
 <20220622224729.kf7xvrky4f7hs4an@yuggoth.org>
 <CAKcU8Z3MrsWEb6ocgNhn8P_Dh-dh3xYSH5=-tPRGLPa9Qaqq3A@mail.gmail.com>
 <CAKcU8Z3brMrY7V8EV9U1Dt2+Ebx-CGnCTVUf7h3DT+f5npLpAw@mail.gmail.com>
Message-ID: <91f6cc534d23a19e80dad34380e83002f187f445.camel@intel.com>

Hi Andreea,

Thanks for bringing this to my attention.

On Tue, 2022-07-05 at 16:37 +0300, Andreea Florescu wrote:
> Gerry, Rob, Sebastien, what do you think about this?
> I would like to go ahead with the license change to Apache 2.0 OR
> BSD-3-Clause and it would be great to also get an ACK from you.
> 

I followed up on the GitHub issue: 
https://github.com/rust-vmm/vmm-sys-util/issues/161

Cheers,

Rob

> Thanks,
> Andreea
> 
> On Thu, Jun 30, 2022 at 10:01 AM Andreea Florescu
> <andreea.florescu15 at gmail.com> wrote:
> > I just wanted to clarify something as well, I do not feel strongly
> > about changing the license to BSD-3-Clause, we can also use Apache
> > 2.0 OR BSD-3-Clause if that makes sense. My interest is to fix the
> > problem initially reported which significantly limits the
> > usefulness of this project as it cannot be used by projects like
> > QEMU.
> > As most contributions are coming from Google (indirectly), Amazon,
> > Intel and Alibaba, it would be really helpful to also get input on
> > updating the license from the folks that are contributing from the
> > respective companies. From the Amazon side of things, we discussed
> > this internally and we're onboard with the change.
> > 
> > Thanks,
> > Andreea
> > 
> > On Thu, Jun 23, 2022 at 1:48 AM Jeremy Stanley <fungi at yuggoth.org>
> > wrote:
> > > On 2022-06-22 17:30:37 +0100 (+0100), Alberto Faria wrote:
> > > [...]
> > > > I may be misunderstanding this, but it sounds like you're
> > > > assuming
> > > > that Apache-2.0 is a superset of BSD-3-clause in terms of user
> > > > obligations. I have no idea if this is actually the case or
> > > > not, but
> > > > if it is, then "Apache-2.0 OR BSD-3-clause" == "BSD-3-clause",
> > > > which
> > > > in a sense contradicts the wide use of the former in Rust
> > > > crates.
> > > [...]
> > > 
> > > I'm not a lawyer, but my long-time understanding has been that
> > > when
> > > you distribute software under "license x or license y" that
> > > allows
> > > people who are receiving and possibly redistributing and deriving
> > > that software to do so based on their choice of either license.
> > > Blanket statements like this are rarely helpful however when the
> > > software consists of parts under different licenses, such as
> > > shipping some files under BSD-3-clause and other files under
> > > Apache-2.0 as part of the same project. Under those
> > > circumstances,
> > > the sum total of the software is effectively held to the union of
> > > the requirements for both licenses, but for permissive-style
> > > licenses like these it's also not expected that the licenses of
> > > some
> > > files impact the licenses of the other files, so long as the
> > > chosen
> > > licenses have compatible terms (permissive-style licenses do not
> > > require you to distribute derivative works under the same terms).
> > > 
> > > The situation changes dramatically when copyleft-style licenses
> > > are
> > > involved, since they often (as is the case with GPL for example)
> > > convey transitive requirements which forbid additional licensing
> > > requirements on the complete work and require redistribution
> > > under
> > > the same license instead.
> > > 
> > > As for whether Apache-2.0 is a superset of BSD-3-clause, that's
> > > implied by its ancestry, since the original Apache license was
> > > effectively a direct copy of BSD-4-clause, and then for Apache-
> > > 1.1
> > > the authors dropped the advertising clause that Berkeley had also
> > > dropped, making it then equivalent to BSD-3-clause. Apache-2.0 is
> > > a
> > > superset of the requirements of Apache-1.1 (and so BSD-3-clause)
> > > as
> > > it merely adds a grant of patent license to the original terms.


From alex.bennee at linaro.org  Wed Jul 13 15:39:23 2022
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 13 Jul 2022 16:39:23 +0100
Subject: [Rust-VMM] Add Xen support to vmm-reference? (was Re: Call for
 topics and skipping next weeks sync)
In-Reply-To: <BY5PR02MB67540B7522A8A5EDD627759EB0899@BY5PR02MB6754.namprd02.prod.outlook.com>
References: <8735f5s6n7.fsf@linaro.org>
 <BY5PR02MB67540B7522A8A5EDD627759EB0899@BY5PR02MB6754.namprd02.prod.outlook.com>
Message-ID: <87o7xtqa92.fsf@linaro.org>


(added xen/rust-vmm to CC)

Trilok Soni <tsoni at quicinc.com> writes:

> Hello Alex,
>
> It would be good to check if there is a enough interest to make
> "vmm-reference" extended to work w/ Type-1 Hypervisor like Xen. This
> will clean-up vmm-reference w/ KVM references, and it will be a good
> independent tool to test the new interfaces additions in the rust-vmm.
>
> https://github.com/rust-vmm/vmm-reference

We have certainly talked about it before and the we've put in some of
the groundwork with the xen-sys crate
(https://github.com/rust-vmm/xen-sys) which we are using for the
xen-vhost-master work. Off the top of my head we would need to work out:

  - Which additional APIs need implementing for VMM lifecycle management
  - How the run loop would look
    - AIUI Hyper-V munges this for rust-vmm by providing a KVM-like
      ioctl API (POC via CrosVM: https://github.com/petrutlucian94/crosvm/tree/windows)
    - See also https://github.com/rust-vmm/community/issues/121
  - Would we aim for full independence from the exiting Xen userspace libs?
    - xen-vhost-master was brought up using them, now slowly being
      replaced with pure rust

I've added it as a discussion topic for the sync call:

  https://calendar.google.com/event?action=TEMPLATE&tmeid=NW83NXNsZ2Q1NmF0bTE0dGNkM3Q0YjFrcTlfMjAyMjA4MDNUMTUwMDAwWiBjX2o3bmdpMW84cmxvZmtwZWQ0cjVjaDk4bXZnQGc&tmsrc=c_j7ngi1o8rlofkped4r5ch98mvg%40group.calendar.google.com

It would be great is we could get any interested folks from the rust-vmm
and Xen communities to come along to the call.

>
> ---Trilok Soni
>
> -----Original Message-----
> From: Alex Benn?e <alex.bennee at linaro.org> 
> Sent: Wednesday, July 13, 2022 2:16 AM
> To: Stratos Mailing List <stratos-dev at op-lists.linaro.org>
> Cc: Viresh Kumar <viresh.kumar at linaro.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; Mike Holmes <mike.holmes at linaro.org>;
> Azzedine Touzni <atouzni at qti.qualcomm.com>; Stefano Stabellini
> <stefano.stabellini at xilinx.com>; Christopher Clark
> <christopher.w.clark at gmail.com>; Arnd Bergmann
> <arnd.bergmann at linaro.org>; Peter Griffin <peter.griffin at linaro.org>;
> AKASHI Takahiro <takahiro.akashi at linaro.org>; Artem Mygaiev
> <Artem_Mygaiev at epam.com>; Leonardo Garcia
> <leonardo.garcia at linaro.org>; Trilok Soni <tsoni at quicinc.com>; Randy
> Linnell <randy.linnell at linaro.org>; don.harbin at linaro.org; Sumit
> Semwal <sumit.semwal at linaro.org>
> Subject: Call for topics and skipping next weeks sync
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>
> Hi All,
>
> I'll be on holiday (moving house) next week so I won't be able to
> chair the Stratos sync meeting. As it is the middle of summer I'm
> going to propose we skip next weeks sync and re-convene on the 3rd of
> August. Any objections?
>
> While on the subject of sync meetings are there any topics to discuss.
> We've had some discussions on next rust-vmm device to implement but
> beyond a vague "maybe virtio-gpu to help with demos" I don't think
> we've nailed it down. virtio-can also keeps getting mentioned and
> while useful I'm wary it's not pushing our exploration of the
> possibilities of virtio further.
>
> I did a talk at GST22 last week which was an overview of VirtIO and what we had done so far as well as discussing some future directions. You can see the talk at:
>
>   https://huawei-events.de/en/gsts22-j83dco-vod.htm
>   (Day 2 stream, Chapter 6/TS 05:13:00)
>
> In it potential future areas of exploration where:
>
> Improve Xen API
> ???????????????
>
>   ? More standard mmap
>   ? direct irqfd/eventfd routing
>
> Memory Isolation
> ????????????????
>
>   ? fat virtqueue
>   ? iommu/grants vs regions
>   (x-over with pKVM/CCA?)
>
> Bare metal rust
> ???????????????
>
>   ? re-use exiting VirtIO logic
>   ? but without POSIX layer
>
> I'd like to get a better steer on what we should focus on next after we've demoed our existing rust-vmm daemons and the Xen vhost-master work.


-- 
Alex Benn?e


From Artem_Mygaiev at epam.com  Fri Jul 15 10:59:42 2022
From: Artem_Mygaiev at epam.com (Artem Mygaiev)
Date: Fri, 15 Jul 2022 10:59:42 +0000
Subject: [Rust-VMM] Add Xen support to vmm-reference? (was Re: Call for
 topics and skipping next weeks sync)
In-Reply-To: <87o7xtqa92.fsf@linaro.org>
References: <8735f5s6n7.fsf@linaro.org>
 <BY5PR02MB67540B7522A8A5EDD627759EB0899@BY5PR02MB6754.namprd02.prod.outlook.com>
 <87o7xtqa92.fsf@linaro.org>
Message-ID: <AM9PR03MB7680EFA0E9F1BD182641CA20F48B9@AM9PR03MB7680.eurprd03.prod.outlook.com>

+ Oleksandr Tyshchenko

-- Artem
________________________________
From: Alex Benn?e <alex.bennee at linaro.org>
Sent: Wednesday, July 13, 2022 6:39:23 PM
To: Trilok Soni <tsoni at quicinc.com>
Cc: Stratos Mailing List <stratos-dev at op-lists.linaro.org>; Viresh Kumar <viresh.kumar at linaro.org>; Mathieu Poirier <mathieu.poirier at linaro.org>; Mike Holmes <mike.holmes at linaro.org>; Azzedine Touzni <atouzni at qti.qualcomm.com>; Stefano Stabellini <stefano.stabellini at xilinx.com>; Christopher Clark <christopher.w.clark at gmail.com>; Arnd Bergmann <arnd.bergmann at linaro.org>; Peter Griffin <peter.griffin at linaro.org>; AKASHI Takahiro <takahiro.akashi at linaro.org>; Artem Mygaiev <Artem_Mygaiev at epam.com>; Leonardo Garcia <leonardo.garcia at linaro.org>; Randy Linnell <randy.linnell at linaro.org>; don.harbin at linaro.org <don.harbin at linaro.org>; Sumit Semwal <sumit.semwal at linaro.org>; xen-devel at lists.xenproject.org <xen-devel at lists.xenproject.org>; Wei Liu <wl at xen.org>; Florescu, Andreea <fandree at amazon.com>; rust-vmm at lists.opendev.org <rust-vmm at lists.opendev.org>
Subject: Add Xen support to vmm-reference? (was Re: Call for topics and skipping next weeks sync)


(added xen/rust-vmm to CC)

Trilok Soni <tsoni at quicinc.com> writes:

> Hello Alex,
>
> It would be good to check if there is a enough interest to make
> "vmm-reference" extended to work w/ Type-1 Hypervisor like Xen. This
> will clean-up vmm-reference w/ KVM references, and it will be a good
> independent tool to test the new interfaces additions in the rust-vmm.
>
> https://urldefense.com/v3/__https://github.com/rust-vmm/vmm-reference__;!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mJWtnJ2Z$ [github[.]com]

We have certainly talked about it before and the we've put in some of
the groundwork with the xen-sys crate
(https://urldefense.com/v3/__https://github.com/rust-vmm/xen-sys__;!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mJRsjZzU$ [github[.]com]) which we are using for the
xen-vhost-master work. Off the top of my head we would need to work out:

  - Which additional APIs need implementing for VMM lifecycle management
  - How the run loop would look
    - AIUI Hyper-V munges this for rust-vmm by providing a KVM-like
      ioctl API (POC via CrosVM: https://urldefense.com/v3/__https://github.com/petrutlucian94/crosvm/tree/windows__;!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mNH1mFFW$ [github[.]com])
    - See also https://urldefense.com/v3/__https://github.com/rust-vmm/community/issues/121__;!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mOE_Kgjx$ [github[.]com]
  - Would we aim for full independence from the exiting Xen userspace libs?
    - xen-vhost-master was brought up using them, now slowly being
      replaced with pure rust

I've added it as a discussion topic for the sync call:

  https://urldefense.com/v3/__https://calendar.google.com/event?action=TEMPLATE&tmeid=NW83NXNsZ2Q1NmF0bTE0dGNkM3Q0YjFrcTlfMjAyMjA4MDNUMTUwMDAwWiBjX2o3bmdpMW84cmxvZmtwZWQ0cjVjaDk4bXZnQGc&tmsrc=c_j7ngi1o8rlofkped4r5ch98mvg*40group.calendar.google.com__;JQ!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mIAXRpBH$ [calendar[.]google[.]com]

It would be great is we could get any interested folks from the rust-vmm
and Xen communities to come along to the call.

>
> ---Trilok Soni
>
> -----Original Message-----
> From: Alex Benn?e <alex.bennee at linaro.org>
> Sent: Wednesday, July 13, 2022 2:16 AM
> To: Stratos Mailing List <stratos-dev at op-lists.linaro.org>
> Cc: Viresh Kumar <viresh.kumar at linaro.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; Mike Holmes <mike.holmes at linaro.org>;
> Azzedine Touzni <atouzni at qti.qualcomm.com>; Stefano Stabellini
> <stefano.stabellini at xilinx.com>; Christopher Clark
> <christopher.w.clark at gmail.com>; Arnd Bergmann
> <arnd.bergmann at linaro.org>; Peter Griffin <peter.griffin at linaro.org>;
> AKASHI Takahiro <takahiro.akashi at linaro.org>; Artem Mygaiev
> <Artem_Mygaiev at epam.com>; Leonardo Garcia
> <leonardo.garcia at linaro.org>; Trilok Soni <tsoni at quicinc.com>; Randy
> Linnell <randy.linnell at linaro.org>; don.harbin at linaro.org; Sumit
> Semwal <sumit.semwal at linaro.org>
> Subject: Call for topics and skipping next weeks sync
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>
> Hi All,
>
> I'll be on holiday (moving house) next week so I won't be able to
> chair the Stratos sync meeting. As it is the middle of summer I'm
> going to propose we skip next weeks sync and re-convene on the 3rd of
> August. Any objections?
>
> While on the subject of sync meetings are there any topics to discuss.
> We've had some discussions on next rust-vmm device to implement but
> beyond a vague "maybe virtio-gpu to help with demos" I don't think
> we've nailed it down. virtio-can also keeps getting mentioned and
> while useful I'm wary it's not pushing our exploration of the
> possibilities of virtio further.
>
> I did a talk at GST22 last week which was an overview of VirtIO and what we had done so far as well as discussing some future directions. You can see the talk at:
>
>   https://urldefense.com/v3/__https://huawei-events.de/en/gsts22-j83dco-vod.htm__;!!GF_29dbcQIUBPA!0uj77Sl-hZVdR69XuAaDLI87ksTktSzE3-q2uL70xlReH_QbkDrjnvdm9fM0E5PeeK5iisOpQTs9Qf79mAohQusR$ [huawei-events[.]de]
>   (Day 2 stream, Chapter 6/TS 05:13:00)
>
> In it potential future areas of exploration where:
>
> Improve Xen API
> ???????????????
>
>   ? More standard mmap
>   ? direct irqfd/eventfd routing
>
> Memory Isolation
> ????????????????
>
>   ? fat virtqueue
>   ? iommu/grants vs regions
>   (x-over with pKVM/CCA?)
>
> Bare metal rust
> ???????????????
>
>   ? re-use exiting VirtIO logic
>   ? but without POSIX layer
>
> I'd like to get a better steer on what we should focus on next after we've demoed our existing rust-vmm daemons and the Xen vhost-master work.


--
Alex Benn?e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.opendev.org/pipermail/rust-vmm/attachments/20220715/4f566b03/attachment-0001.htm>