From stefanha at redhat.com  Mon Mar  1 11:05:42 2021
From: stefanha at redhat.com (Stefan Hajnoczi)
Date: Mon, 1 Mar 2021 11:05:42 +0000
Subject: [Rust-VMM] [virtio-dev] [VHOST USER SPEC PATCH] vhost-user.rst:
 add clarifying language about protocol negotiation
In-Reply-To: <20210226111619.21178-1-alex.bennee@linaro.org>
References: <20210226111619.21178-1-alex.bennee@linaro.org>
Message-ID: <YDzKhnQa+LS01yTN@stefanha-x1.localdomain>

On Fri, Feb 26, 2021 at 11:16:19AM +0000, Alex Bennée wrote:
> In practice the protocol negotiation between vhost master and slave
> occurs before the final feature negotiation between backend and
> frontend. This has lead to an inconsistency between the rust-vmm vhost
> implementation and the libvhost-user library in their approaches to
> checking if all the requirements for REPLY_ACK processing were met.
> As this is purely a function of the protocol negotiation and not of
> interest to the frontend lets make the language clearer about the
> requirements for a successfully negotiated protocol feature.
> 
> Signed-off-by: Alex Bennée <alex.bennee at linaro.org>
> Cc: Jiang Liu <gerry at linux.alibaba.com>
> ---
>  docs/interop/vhost-user.rst | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)

I had difficulty understanding this change and its purpose. I think it's
emphasizing what the spec already says: VHOST_USER_SET_PROTOCOL_FEATURES
can be sent after VHOST_USER_F_PROTOCOL_FEATURES was reported by
VHOST_USER_GET_FEATURES.

BTW Paolo has just sent a patch here to use the terms "frontend" and
"backend" with different meanings from how you are using them:
https://lists.nongnu.org/archive/html/qemu-devel/2021-02/msg08347.html

> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
> index d6085f7045..3ac221a8c7 100644
> --- a/docs/interop/vhost-user.rst
> +++ b/docs/interop/vhost-user.rst
> @@ -301,12 +301,22 @@ If *slave* detects some error such as incompatible features, it may also
>  close the connection. This should only happen in exceptional circumstances.
>  
>  Any protocol extensions are gated by protocol feature bits, which
> -allows full backwards compatibility on both master and slave.  As
> -older slaves don't support negotiating protocol features, a feature
> +allows full backwards compatibility on both master and slave. As older
> +slaves don't support negotiating protocol features, a device feature
>  bit was dedicated for this purpose::
>  
>    #define VHOST_USER_F_PROTOCOL_FEATURES 30
>  
> +However as the protocol negotiation something that only occurs between

Missing "is". Shortening the sentence fixes that without losing clarity:
s/something that/negotiation/

> +parts of the backend implementation it is permissible to for the master

"vhost-user device backend" is often used to refer to the slave (to
avoid saying the word "slave") but "backend" is being used in a
different sense here. That is confusing.

> +to mask the feature bit from the guest.

I think this sentence effectively says "the master MAY mask the
VHOST_USER_F_PROTOCOL_FEATURES bit from the VIRTIO feature bits". That
is not really accurate since VIRTIO devices do not advertise this
feature bit and so it can never be negotiated through the VIRTIO feature
negotiation process.

How about referring to the details from the VIRTIO 1.1 specification
instead. Something like this:

  Note that VHOST_USER_F_PROTOCOL_FEATURES is the UNUSED (30) feature
  bit defined in `VIRTIO 1.1 6.3 Legacy Interface: Reserved Feature Bits
  <https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-4130003>`_.
  VIRTIO devices do not advertise this feature bit and therefore VIRTIO
  drivers cannot negotiate it.

  This reserved feature bit was reused by the vhost-user protocol to add
  vhost-user protocol feature negotiation in a backwards compatible
  fashion. Old vhost-user master and slave implementations continue to
  work even though they are not aware of vhost-user protocol feature
  negotiation.

> As noted for the
> +``VHOST_USER_GET_PROTOCOL_FEATURES`` and
> +``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a
> +final ``VHOST_USER_SET_FEATURES`` comes from the guest.

I couldn't find any place where vhost-user.rst states that
VHOST_USER_SET_PROTOCOL_FEATURES has to come before
VHOST_USER_SET_FEATURES?

The only order I found was:

1. VHOST_USER_GET_FEATURES to determine whether protocol features are
   supported.
2. VHOST_USER_GET_PROTOCOL_FEATURES to fetch available protocol feature bits.
3. VHOST_USER_SET_PROTOCOL_FEATURES to set protocol feature bits.
4. Using functionality that depends on enabled protocol feature bits.

Is the purpose of this sentence to add a new requirement to the spec
that "VHOST_USER_SET_PROTOCOL_FEATURES MUST be sent before
VHOST_USER_SET_FEATURES"?

> So the
> +enabling of protocol features need only require the advertising of the
> +feature by the slave and the successful get/set protocol features
> +sequence.

"the feature" == VHOST_USER_F_PROTOCOL_FEATURES?

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210301/9fa284f8/attachment.sig>

From fandree at amazon.com  Mon Mar  1 11:05:31 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Mon, 1 Mar 2021 11:05:31 +0000
Subject: [Rust-VMM] [Action Required] rust-vmm sync meetings
In-Reply-To: <1614000270456.88753@amazon.com>
References: <1614000270456.88753@amazon.com>
Message-ID: <1614596731050.92790@amazon.com>

Hey everyone,


Thanks for responding to the poll.

I must admit it looks a bit like an impossible mission to schedule a meeting in which most community members are available.


To allow everyone to join the sync meeting at least from time to time, what do you think about the following proposal:

- one sync meeting happens from 10-11 AM CET (this was the most popular choice in the poll)

- the next sync meeting happens from 5-6 PM CET (this was the choice where most people that did not vote for the first choice were available)


The schedule for the next 4 meetings would be as follows:
- on 2021-03-08, we meet at 10 AM CET

- on 2021-03-22, we meet at 5 PM CET

- on 2021-04-05, we meet at 10 AM CET

- on 2021-04-19, we meet at 5 PM CET


Hope that makes sense.


I would also be interested in finding out if you know of how other open source communities are handling this kind of sync meetings, and if there is another approach that we could take.

Before scheduling the recurring meeting, I'll just wait a couple more days to see if other people have any other ideas on how we can handle this.


I've created a new etherpad for taking meeting notes here: https://etherpad.opendev.org/p/rust-vmm-sync-2021. If you have any topics that you'd like to discuss, please add them to the document.?


Thanks,

Andreea

________________________________
From: Florescu, Andreea <fandree at amazon.com>
Sent: Monday, February 22, 2021 3:24 PM
To: rust-vmm at lists.opendev.org
Subject: [UNVERIFIED SENDER] [Rust-VMM] [Action Required] rust-vmm sync meetings


Hey folks,


In the last week sync meeting we discussed about recreating the bi-weekly rust-vmm sync meeting.

I created a poll to see when most people can join: https://doodle.com/poll/nrrsivwytgc5zy9n?utm_source=poll&utm_medium=link

?

The poll will close on 2021-03-01 so please choose your preferred hour by then. I'll schedule recurring meetings (every 2 weeks, on Monday) starting with ?2021-03-08.


Thanks,

Andreea

Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210301/eaf85e9b/attachment.html>

From alex.bennee at linaro.org  Mon Mar  1 11:38:47 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Mon, 01 Mar 2021 11:38:47 +0000
Subject: [Rust-VMM] [virtio-dev] [VHOST USER SPEC PATCH] vhost-user.rst:
 add clarifying language about protocol negotiation
In-Reply-To: <YDzKhnQa+LS01yTN@stefanha-x1.localdomain>
References: <20210226111619.21178-1-alex.bennee@linaro.org>
 <YDzKhnQa+LS01yTN@stefanha-x1.localdomain>
Message-ID: <87czwjjdf7.fsf@linaro.org>


Stefan Hajnoczi <stefanha at redhat.com> writes:

> On Fri, Feb 26, 2021 at 11:16:19AM +0000, Alex Bennée wrote:
>> In practice the protocol negotiation between vhost master and slave
>> occurs before the final feature negotiation between backend and
>> frontend. This has lead to an inconsistency between the rust-vmm vhost
>> implementation and the libvhost-user library in their approaches to
>> checking if all the requirements for REPLY_ACK processing were met.
>> As this is purely a function of the protocol negotiation and not of
>> interest to the frontend lets make the language clearer about the
>> requirements for a successfully negotiated protocol feature.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee at linaro.org>
>> Cc: Jiang Liu <gerry at linux.alibaba.com>
>> ---
>>  docs/interop/vhost-user.rst | 14 ++++++++++++--
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> I had difficulty understanding this change and its purpose. I think it's
> emphasizing what the spec already says: VHOST_USER_SET_PROTOCOL_FEATURES
> can be sent after VHOST_USER_F_PROTOCOL_FEATURES was reported by
> VHOST_USER_GET_FEATURES.

Well and also the protocol feature is considered negotiated after that
sequence and doesn't require the feature bit to also be negotiated. I
think I read the spec properly when I submitted:

  https://github.com/rust-vmm/vhost/pull/24

however it was implied rather than explicit. I was hoping to make that
clearer but obviously I've failed with this iteration.

> BTW Paolo has just sent a patch here to use the terms "frontend" and
> "backend" with different meanings from how you are using them:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-02/msg08347.html

Yeah we have mixed up terminology - the relationship between QEMU and a
vhost-user daemon is separate from the relationship between a VirtIO
device driver (in the guest) and the device implementation (as done by
the combination of QEMU and the vhost-user daemon).

I wish we had clearer terminology sections throughout both specs.

>
>> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
>> index d6085f7045..3ac221a8c7 100644
>> --- a/docs/interop/vhost-user.rst
>> +++ b/docs/interop/vhost-user.rst
>> @@ -301,12 +301,22 @@ If *slave* detects some error such as incompatible features, it may also
>>  close the connection. This should only happen in exceptional circumstances.
>>  
>>  Any protocol extensions are gated by protocol feature bits, which
>> -allows full backwards compatibility on both master and slave.  As
>> -older slaves don't support negotiating protocol features, a feature
>> +allows full backwards compatibility on both master and slave. As older
>> +slaves don't support negotiating protocol features, a device feature
>>  bit was dedicated for this purpose::
>>  
>>    #define VHOST_USER_F_PROTOCOL_FEATURES 30
>>  
>> +However as the protocol negotiation something that only occurs between
>
> Missing "is". Shortening the sentence fixes that without losing clarity:
> s/something that/negotiation/
>
>> +parts of the backend implementation it is permissible to for the master
>
> "vhost-user device backend" is often used to refer to the slave (to
> avoid saying the word "slave") but "backend" is being used in a
> different sense here. That is confusing.
>
>> +to mask the feature bit from the guest.
>
> I think this sentence effectively says "the master MAY mask the
> VHOST_USER_F_PROTOCOL_FEATURES bit from the VIRTIO feature bits". That
> is not really accurate since VIRTIO devices do not advertise this
> feature bit and so it can never be negotiated through the VIRTIO feature
> negotiation process.
>
> How about referring to the details from the VIRTIO 1.1 specification
> instead. Something like this:
>
>   Note that VHOST_USER_F_PROTOCOL_FEATURES is the UNUSED (30) feature
>   bit defined in `VIRTIO 1.1 6.3 Legacy Interface: Reserved Feature Bits
>   <https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-4130003>`_.
>   VIRTIO devices do not advertise this feature bit and therefore VIRTIO
>   drivers cannot negotiate it.
>
>   This reserved feature bit was reused by the vhost-user protocol to add
>   vhost-user protocol feature negotiation in a backwards compatible
>   fashion. Old vhost-user master and slave implementations continue to
>   work even though they are not aware of vhost-user protocol feature
>   negotiation.

OK - so does that mean that feature bit will remain UNUSED for ever
more?

What about other feature bits? Is it permissible for the
master/requester/vhost-user front-end/QEMU to filter any other feature
bits the slave/vhost-user backend/daemon may offer from being read by
the guest driver when it reads the feature bits?

>
>> As noted for the
>> +``VHOST_USER_GET_PROTOCOL_FEATURES`` and
>> +``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a
>> +final ``VHOST_USER_SET_FEATURES`` comes from the guest.
>
> I couldn't find any place where vhost-user.rst states that
> VHOST_USER_SET_PROTOCOL_FEATURES has to come before
> VHOST_USER_SET_FEATURES?
>
> The only order I found was:
>
> 1. VHOST_USER_GET_FEATURES to determine whether protocol features are
>    supported.
> 2. VHOST_USER_GET_PROTOCOL_FEATURES to fetch available protocol feature bits.
> 3. VHOST_USER_SET_PROTOCOL_FEATURES to set protocol feature bits.
> 4. Using functionality that depends on enabled protocol feature bits.
>
> Is the purpose of this sentence to add a new requirement to the spec
> that "VHOST_USER_SET_PROTOCOL_FEATURES MUST be sent before
> VHOST_USER_SET_FEATURES"?

No I don't want to add a new sequence requirement. But if SET_FEATURES
doesn't acknowledge the VHOST_USER_F_PROTOCOL_FEATURES bit should that
stop the processing of
VHOST_USER_GET_PROTOCOL_FEATURES/VHOST_USER_SET_PROTOCOL_FEATURES
messages? AFAICT SET_FEATURES should be irrelevant to the negotiation of
the PROTOCOL_FEATURES right?

>> So the
>> +enabling of protocol features need only require the advertising of the
>> +feature by the slave and the successful get/set protocol features
>> +sequence.
>
> "the feature" == VHOST_USER_F_PROTOCOL_FEATURES?

yes.

>
> Stefan


-- 
Alex Bennée


From stefanha at redhat.com  Mon Mar  1 16:35:51 2021
From: stefanha at redhat.com (Stefan Hajnoczi)
Date: Mon, 1 Mar 2021 16:35:51 +0000
Subject: [Rust-VMM] [virtio-dev] [VHOST USER SPEC PATCH] vhost-user.rst:
 add clarifying language about protocol negotiation
In-Reply-To: <87czwjjdf7.fsf@linaro.org>
References: <20210226111619.21178-1-alex.bennee@linaro.org>
 <YDzKhnQa+LS01yTN@stefanha-x1.localdomain>
 <87czwjjdf7.fsf@linaro.org>
Message-ID: <YD0X58hj+al5uPWk@stefanha-x1.localdomain>

On Mon, Mar 01, 2021 at 11:38:47AM +0000, Alex Bennée wrote:
> Stefan Hajnoczi <stefanha at redhat.com> writes:
> > On Fri, Feb 26, 2021 at 11:16:19AM +0000, Alex Bennée wrote:
> >> +However as the protocol negotiation something that only occurs between
> >
> > Missing "is". Shortening the sentence fixes that without losing clarity:
> > s/something that/negotiation/
> >
> >> +parts of the backend implementation it is permissible to for the master
> >
> > "vhost-user device backend" is often used to refer to the slave (to
> > avoid saying the word "slave") but "backend" is being used in a
> > different sense here. That is confusing.
> >
> >> +to mask the feature bit from the guest.
> >
> > I think this sentence effectively says "the master MAY mask the
> > VHOST_USER_F_PROTOCOL_FEATURES bit from the VIRTIO feature bits". That
> > is not really accurate since VIRTIO devices do not advertise this
> > feature bit and so it can never be negotiated through the VIRTIO feature
> > negotiation process.
> >
> > How about referring to the details from the VIRTIO 1.1 specification
> > instead. Something like this:
> >
> >   Note that VHOST_USER_F_PROTOCOL_FEATURES is the UNUSED (30) feature
> >   bit defined in `VIRTIO 1.1 6.3 Legacy Interface: Reserved Feature Bits
> >   <https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-4130003>`_.
> >   VIRTIO devices do not advertise this feature bit and therefore VIRTIO
> >   drivers cannot negotiate it.
> >
> >   This reserved feature bit was reused by the vhost-user protocol to add
> >   vhost-user protocol feature negotiation in a backwards compatible
> >   fashion. Old vhost-user master and slave implementations continue to
> >   work even though they are not aware of vhost-user protocol feature
> >   negotiation.
> 
> OK - so does that mean that feature bit will remain UNUSED for ever
> more?

It's unlikely to be repurposed in VIRTIO. It can never be used by VIRTIO
in a situation that overlaps with vhost-user. That leaves cases that
don't overlap with vhost-user but that is unlikely too since the bit had
a previous meaning (before vhost-user) and repurposing it would cause
confusion for very old drivers or devices.

> What about other feature bits? Is it permissible for the
> master/requester/vhost-user front-end/QEMU to filter any other feature
> bits the slave/vhost-user backend/daemon may offer from being read by
> the guest driver when it reads the feature bits?

Yes, the vhost-user frontend can decide how it wants to expose
VHOST_USER_GET_FEATURES feature bits on the VIRTIO device:

1. Pass-through. Allow the vhost-user device backend to control the
   feature bit.
2. Disabling. Clear a feature bit because it cannot be supported for
   some reason (e.g. VIRTIO 1.1 packed vrings are not implemented and
   therefore enabling them would prevent live migration).
3. Enabling. Enable a feature bit that does not rely on vhost-user
   device backend support. For example, message-signalled interrupts
   for virtio-mmio.

> 
> >
> >> As noted for the
> >> +``VHOST_USER_GET_PROTOCOL_FEATURES`` and
> >> +``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a
> >> +final ``VHOST_USER_SET_FEATURES`` comes from the guest.
> >
> > I couldn't find any place where vhost-user.rst states that
> > VHOST_USER_SET_PROTOCOL_FEATURES has to come before
> > VHOST_USER_SET_FEATURES?
> >
> > The only order I found was:
> >
> > 1. VHOST_USER_GET_FEATURES to determine whether protocol features are
> >    supported.
> > 2. VHOST_USER_GET_PROTOCOL_FEATURES to fetch available protocol feature bits.
> > 3. VHOST_USER_SET_PROTOCOL_FEATURES to set protocol feature bits.
> > 4. Using functionality that depends on enabled protocol feature bits.
> >
> > Is the purpose of this sentence to add a new requirement to the spec
> > that "VHOST_USER_SET_PROTOCOL_FEATURES MUST be sent before
> > VHOST_USER_SET_FEATURES"?
> 
> No I don't want to add a new sequence requirement. But if SET_FEATURES
> doesn't acknowledge the VHOST_USER_F_PROTOCOL_FEATURES bit should that
> stop the processing of
> VHOST_USER_GET_PROTOCOL_FEATURES/VHOST_USER_SET_PROTOCOL_FEATURES
> messages? AFAICT SET_FEATURES should be irrelevant to the negotiation of
> the PROTOCOL_FEATURES right?

I agree, the value of VHOST_USER_F_PROTOCOL_FEATURES in
VHOST_USER_SET_FEATURES does not matter according to the spec:

  Only legal if feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` is
  present in ``VHOST_USER_GET_FEATURES``.

Since it does not mention "set in VHOST_USER_SET_FEATURES" we have to
assume existing vhost-user device backends do not care whether the
vhost-user frontend includes the bit in VHOST_USER_SET_FEATURES or not.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210301/bb0ac464/attachment.sig>

From mst at redhat.com  Mon Mar  1 17:18:25 2021
From: mst at redhat.com (Michael S. Tsirkin)
Date: Mon, 1 Mar 2021 12:18:25 -0500
Subject: [Rust-VMM] [virtio-dev] [VHOST USER SPEC PATCH] vhost-user.rst:
 add clarifying language about protocol negotiation
In-Reply-To: <YD0X58hj+al5uPWk@stefanha-x1.localdomain>
References: <20210226111619.21178-1-alex.bennee@linaro.org>
 <YDzKhnQa+LS01yTN@stefanha-x1.localdomain>
 <87czwjjdf7.fsf@linaro.org>
 <YD0X58hj+al5uPWk@stefanha-x1.localdomain>
Message-ID: <20210301121623-mutt-send-email-mst@kernel.org>

On Mon, Mar 01, 2021 at 04:35:51PM +0000, Stefan Hajnoczi wrote:
> On Mon, Mar 01, 2021 at 11:38:47AM +0000, Alex Bennée wrote:
> > Stefan Hajnoczi <stefanha at redhat.com> writes:
> > > On Fri, Feb 26, 2021 at 11:16:19AM +0000, Alex Bennée wrote:
> > >> +However as the protocol negotiation something that only occurs between
> > >
> > > Missing "is". Shortening the sentence fixes that without losing clarity:
> > > s/something that/negotiation/
> > >
> > >> +parts of the backend implementation it is permissible to for the master
> > >
> > > "vhost-user device backend" is often used to refer to the slave (to
> > > avoid saying the word "slave") but "backend" is being used in a
> > > different sense here. That is confusing.
> > >
> > >> +to mask the feature bit from the guest.
> > >
> > > I think this sentence effectively says "the master MAY mask the
> > > VHOST_USER_F_PROTOCOL_FEATURES bit from the VIRTIO feature bits". That
> > > is not really accurate since VIRTIO devices do not advertise this
> > > feature bit and so it can never be negotiated through the VIRTIO feature
> > > negotiation process.
> > >
> > > How about referring to the details from the VIRTIO 1.1 specification
> > > instead. Something like this:
> > >
> > >   Note that VHOST_USER_F_PROTOCOL_FEATURES is the UNUSED (30) feature
> > >   bit defined in `VIRTIO 1.1 6.3 Legacy Interface: Reserved Feature Bits
> > >   <https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-4130003>`_.
> > >   VIRTIO devices do not advertise this feature bit and therefore VIRTIO
> > >   drivers cannot negotiate it.
> > >
> > >   This reserved feature bit was reused by the vhost-user protocol to add
> > >   vhost-user protocol feature negotiation in a backwards compatible
> > >   fashion. Old vhost-user master and slave implementations continue to
> > >   work even though they are not aware of vhost-user protocol feature
> > >   negotiation.
> > 
> > OK - so does that mean that feature bit will remain UNUSED for ever
> > more?
> 
> It's unlikely to be repurposed in VIRTIO. It can never be used by VIRTIO
> in a situation that overlaps with vhost-user. That leaves cases that
> don't overlap with vhost-user but that is unlikely too since the bit had
> a previous meaning (before vhost-user) and repurposing it would cause
> confusion for very old drivers or devices.

Yes, it's easier to just use higher bits.
If it ever is reused we will just send that bit separately.

> > What about other feature bits? Is it permissible for the
> > master/requester/vhost-user front-end/QEMU to filter any other feature
> > bits the slave/vhost-user backend/daemon may offer from being read by
> > the guest driver when it reads the feature bits?
> 
> Yes, the vhost-user frontend can decide how it wants to expose
> VHOST_USER_GET_FEATURES feature bits on the VIRTIO device:
> 
> 1. Pass-through. Allow the vhost-user device backend to control the
>    feature bit.
> 2. Disabling. Clear a feature bit because it cannot be supported for
>    some reason (e.g. VIRTIO 1.1 packed vrings are not implemented and
>    therefore enabling them would prevent live migration).
> 3. Enabling. Enable a feature bit that does not rely on vhost-user
>    device backend support. For example, message-signalled interrupts
>    for virtio-mmio.
> 
> > 
> > >
> > >> As noted for the
> > >> +``VHOST_USER_GET_PROTOCOL_FEATURES`` and
> > >> +``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a
> > >> +final ``VHOST_USER_SET_FEATURES`` comes from the guest.
> > >
> > > I couldn't find any place where vhost-user.rst states that
> > > VHOST_USER_SET_PROTOCOL_FEATURES has to come before
> > > VHOST_USER_SET_FEATURES?
> > >
> > > The only order I found was:
> > >
> > > 1. VHOST_USER_GET_FEATURES to determine whether protocol features are
> > >    supported.
> > > 2. VHOST_USER_GET_PROTOCOL_FEATURES to fetch available protocol feature bits.
> > > 3. VHOST_USER_SET_PROTOCOL_FEATURES to set protocol feature bits.
> > > 4. Using functionality that depends on enabled protocol feature bits.
> > >
> > > Is the purpose of this sentence to add a new requirement to the spec
> > > that "VHOST_USER_SET_PROTOCOL_FEATURES MUST be sent before
> > > VHOST_USER_SET_FEATURES"?
> > 
> > No I don't want to add a new sequence requirement. But if SET_FEATURES
> > doesn't acknowledge the VHOST_USER_F_PROTOCOL_FEATURES bit should that
> > stop the processing of
> > VHOST_USER_GET_PROTOCOL_FEATURES/VHOST_USER_SET_PROTOCOL_FEATURES
> > messages? AFAICT SET_FEATURES should be irrelevant to the negotiation of
> > the PROTOCOL_FEATURES right?
> 
> I agree, the value of VHOST_USER_F_PROTOCOL_FEATURES in
> VHOST_USER_SET_FEATURES does not matter according to the spec:
> 
>   Only legal if feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` is
>   present in ``VHOST_USER_GET_FEATURES``.
> 
> Since it does not mention "set in VHOST_USER_SET_FEATURES" we have to
> assume existing vhost-user device backends do not care whether the
> vhost-user frontend includes the bit in VHOST_USER_SET_FEATURES or not.
> 
> Stefan




From kendall at openstack.org  Mon Mar  1 17:44:09 2021
From: kendall at openstack.org (Kendall Waters)
Date: Mon, 1 Mar 2021 11:44:09 -0600
Subject: [Rust-VMM] April 2021 PTG Dates & Registration
Message-ID: <0705F7D2-0A9C-4E18-8C70-F0FC13F78F45@openstack.org>

Hello Everyone!

I'm sure you all have been anxiously awaiting the announcement of the dates for the next virtual PTG[1]! The PTG will take place April 19-23, 2021! 

PTG registration is now open[2]. Like last time, it is free, but we will again be using it to communicate details about the event (schedules, passwords, etc), so please take two minutes to register!

Early next week we will send out info to mailing lists about signing up teams. Also, the same as last time, we will have an ethercalc signup and a survey to gather some other data about your team. 

Can't wait to see you all there!

-the Kendalls (diablo_rojo & wendallkaters)

[1] https://www.openstack.org/ptg/ <https://www.openstack.org/ptg/>
[2] https://april2021-ptg.eventbrite.com <https://april2021-ptg.eventbrite.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210301/fe32b5f8/attachment.html>

From alex.bennee at linaro.org  Wed Mar  3 09:31:41 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 03 Mar 2021 09:31:41 +0000
Subject: [Rust-VMM] [Action Required] rust-vmm sync meetings
In-Reply-To: <1614596731050.92790@amazon.com>
References: <1614000270456.88753@amazon.com> <1614596731050.92790@amazon.com>
Message-ID: <87mtvkin8c.fsf@linaro.org>


Florescu, Andreea <fandree at amazon.com> writes:

> Hey everyone,
>
>
> Thanks for responding to the poll.
>
> I must admit it looks a bit like an impossible mission to schedule a meeting in which most community members are available.
>
>
> To allow everyone to join the sync meeting at least from time to time, what do you think about the following proposal:
>
> - one sync meeting happens from 10-11 AM CET (this was the most popular choice in the poll)
>
> - the next sync meeting happens from 5-6 PM CET (this was the choice
> where most people that did not vote for the first choice were
> available)

This seems a very reasonable approach IMHO.

> The schedule for the next 4 meetings would be as follows:
> - on 2021-03-08, we meet at 10 AM CET
>
> - on 2021-03-22, we meet at 5 PM CET
>
> - on 2021-04-05, we meet at 10 AM CET
>
> - on 2021-04-19, we meet at 5 PM CET
>
>
> Hope that makes sense.
>
>
> I would also be interested in finding out if you know of how other
> open source communities are handling this kind of sync meetings, and
> if there is another approach that we could take.

In my experience (Linux/QEMU) most community syncing is in fact very
asynchronous. The more dispersed your development community the harder
it is to have everyone be awake at the same time. For QEMU there is a
nominated conference call slot every two weeks but it only happens on a
very much ad-hoc basis if there is something that merits discussion that
needs a tighter feedback loop.

In Linaro when we want to sync on something between US/Europe/Asia it
generally means someone is either getting up super early or staying
online later than usual. It does tend to ensure the meeting is worth
having as no one wants to mess with their body clock for something that
isn't interesting to them.

The QEMU project has a fairly active IRC channel but nothing beats email
for getting a wide consideration of a proposal. On the flip side it does
present a barrier to entry for new contributors who generally don't have
the very streamlined email workflows of the old timers. As we slowly
progress to having a more forge like approach to our patch workflow we
have already discussed the importance of keeping the same email
accessibility we have now with our old school lists and archives.

>
> Before scheduling the recurring meeting, I'll just wait a couple more
> days to see if other people have any other ideas on how we can handle
> this.

Will this be a group HO/Zoom/Other?

>
>
> I've created a new etherpad for taking meeting notes here:
> https://etherpad.opendev.org/p/rust-vmm-sync-2021. If you have any
> topics that you'd like to discuss, please add them to the document.?
>
>
> Thanks,
>
> Andreea
>
> ________________________________
> From: Florescu, Andreea <fandree at amazon.com>
> Sent: Monday, February 22, 2021 3:24 PM
> To: rust-vmm at lists.opendev.org
> Subject: [UNVERIFIED SENDER] [Rust-VMM] [Action Required] rust-vmm sync meetings
>
>
> Hey folks,
>
>
> In the last week sync meeting we discussed about recreating the bi-weekly rust-vmm sync meeting.
>
> I created a poll to see when most people can join: https://doodle.com/poll/nrrsivwytgc5zy9n?utm_source=poll&utm_medium=link
>
> ?
>
> The poll will close on 2021-03-01 so please choose your preferred hour by then. I'll schedule recurring meetings (every 2 weeks, on Monday) starting with ?2021-03-08.
>
>
> Thanks,
>
> Andreea
>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
>
>
>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm


-- 
Alex Bennée


From fandree at amazon.com  Wed Mar  3 12:46:38 2021
From: fandree at amazon.com (Andreea Florescu)
Date: Wed, 3 Mar 2021 14:46:38 +0200
Subject: [Rust-VMM] [Action Required] rust-vmm sync meetings
In-Reply-To: <87mtvkin8c.fsf@linaro.org>
References: <1614000270456.88753@amazon.com> <1614596731050.92790@amazon.com>
 <87mtvkin8c.fsf@linaro.org>
Message-ID: <60689607-3730-5adf-d7c6-948a13a37c1c@amazon.com>



On 3/3/21 11:31 AM, Alex Bennée wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Florescu, Andreea <fandree at amazon.com> writes:
>
>> Hey everyone,
>>
>>
>> Thanks for responding to the poll.
>>
>> I must admit it looks a bit like an impossible mission to schedule a meeting in which most community members are available.
>>
>>
>> To allow everyone to join the sync meeting at least from time to time, what do you think about the following proposal:
>>
>> - one sync meeting happens from 10-11 AM CET (this was the most popular choice in the poll)
>>
>> - the next sync meeting happens from 5-6 PM CET (this was the choice
>> where most people that did not vote for the first choice were
>> available)
> This seems a very reasonable approach IMHO.
>
>> The schedule for the next 4 meetings would be as follows:
>> - on 2021-03-08, we meet at 10 AM CET
>>
>> - on 2021-03-22, we meet at 5 PM CET
>>
>> - on 2021-04-05, we meet at 10 AM CET
>>
>> - on 2021-04-19, we meet at 5 PM CET
>>
>>
>> Hope that makes sense.
>>
>>
>> I would also be interested in finding out if you know of how other
>> open source communities are handling this kind of sync meetings, and
>> if there is another approach that we could take.
> In my experience (Linux/QEMU) most community syncing is in fact very
> asynchronous. The more dispersed your development community the harder
> it is to have everyone be awake at the same time. For QEMU there is a
> nominated conference call slot every two weeks but it only happens on a
> very much ad-hoc basis if there is something that merits discussion that
> needs a tighter feedback loop.
>
> In Linaro when we want to sync on something between US/Europe/Asia it
> generally means someone is either getting up super early or staying
> online later than usual. It does tend to ensure the meeting is worth
> having as no one wants to mess with their body clock for something that
> isn't interesting to them.
>
> The QEMU project has a fairly active IRC channel but nothing beats email
> for getting a wide consideration of a proposal. On the flip side it does
> present a barrier to entry for new contributors who generally don't have
> the very streamlined email workflows of the old timers. As we slowly
> progress to having a more forge like approach to our patch workflow we
> have already discussed the importance of keeping the same email
> accessibility we have now with our old school lists and archives.
Thanks for sharing this!
>> Before scheduling the recurring meeting, I'll just wait a couple more
>> days to see if other people have any other ideas on how we can handle
>> this.
> Will this be a group HO/Zoom/Other?
I'll create the meeting series later today. For the previous meeting we
used Chime.
It works fairly well from the browser, and it allows sharing your screen.
If you have any other preferences let me know. I guess the only
requirement is for people to be able to use it without installing
another app.
>
>>
>> I've created a new etherpad for taking meeting notes here:
>> https://etherpad.opendev.org/p/rust-vmm-sync-2021. If you have any
>> topics that you'd like to discuss, please add them to the document.?
>>
>>
>> Thanks,
>>
>> Andreea
>>
>> ________________________________
>> From: Florescu, Andreea <fandree at amazon.com>
>> Sent: Monday, February 22, 2021 3:24 PM
>> To: rust-vmm at lists.opendev.org
>> Subject: [UNVERIFIED SENDER] [Rust-VMM] [Action Required] rust-vmm sync meetings
>>
>>
>> Hey folks,
>>
>>
>> In the last week sync meeting we discussed about recreating the bi-weekly rust-vmm sync meeting.
>>
>> I created a poll to see when most people can join: https://doodle.com/poll/nrrsivwytgc5zy9n?utm_source=poll&utm_medium=link
>>
>> ?
>>
>> The poll will close on 2021-03-01 so please choose your preferred hour by then. I'll schedule recurring meetings (every 2 weeks, on Monday) starting with ?2021-03-08.
>>
>>
>> Thanks,
>>
>> Andreea
>>
>> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
>>
>>
>>
>> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
>> _______________________________________________
>> Rust-vmm mailing list
>> Rust-vmm at lists.opendev.org
>> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
>
> --
> Alex Bennée




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9B51563C1FA36782.asc
Type: application/pgp-keys
Size: 2460 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210303/4a304c71/attachment.key>

From fandree at amazon.com  Wed Mar  3 13:23:52 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Wed, 3 Mar 2021 13:23:52 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
Message-ID: <bf617ea3cc8c4dbeab9b264ae16937b7@EX13D10EUA003.ant.amazon.com>

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 2352511775
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/2352511775
Join via phone (US): +1-929-432-4463,,,2352511775#<tel:+1-929-432-4463,,,2352511775#>
Join via phone (US toll-free): +1-855-552-4463,,,2352511775#<tel:+1-855-552-4463,,,2352511775#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 2352511775#
=================================================




================Before your meeting:================

   *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
   *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
   *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
   *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.
================================================


Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>)



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210303/e5689b27/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 4076 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210303/e5689b27/attachment.ics>

From fandree at amazon.com  Wed Mar  3 13:24:08 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Wed, 3 Mar 2021 13:24:08 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
Message-ID: <84a2cdf66a0b41bba38545b8cb94cf94@EX13D10EUA003.ant.amazon.com>

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 6592165432
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/6592165432
Join via phone (US): +1-929-432-4463,,,6592165432#<tel:+1-929-432-4463,,,6592165432#>
Join via phone (US toll-free): +1-855-552-4463,,,6592165432#<tel:+1-855-552-4463,,,6592165432#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 6592165432#
=================================================




================Before your meeting:================

   *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
   *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
   *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
   *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.
================================================


Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777589627-fandree-1c5b1c7ac9e3d98d02cb97d1a0b6c32c>)



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210303/0355d3d5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 4076 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210303/0355d3d5/attachment-0001.ics>

From alex.bennee at linaro.org  Wed Mar  3 13:32:23 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 03 Mar 2021 13:32:23 +0000
Subject: [Rust-VMM] [Action Required] rust-vmm sync meetings
In-Reply-To: <60689607-3730-5adf-d7c6-948a13a37c1c@amazon.com>
References: <1614000270456.88753@amazon.com>
 <1614596731050.92790@amazon.com> <87mtvkin8c.fsf@linaro.org>
 <60689607-3730-5adf-d7c6-948a13a37c1c@amazon.com>
Message-ID: <87tupsgy26.fsf@linaro.org>


Andreea Florescu <fandree at amazon.com> writes:

<snip>
>>> Before scheduling the recurring meeting, I'll just wait a couple more
>>> days to see if other people have any other ideas on how we can handle
>>> this.
>> Will this be a group HO/Zoom/Other?
> I'll create the meeting series later today. For the previous meeting we
> used Chime.
> It works fairly well from the browser, and it allows sharing your screen.
> If you have any other preferences let me know. I guess the only
> requirement is for people to be able to use it without installing
> another app.

As long as it works in the browser it will be fine. I'm fairly sure one
of the KVM forum BoFs I attended was a Chime session Alexander Graf set
up.

-- 
Alex Bennée


From fandree at amazon.com  Mon Mar  8 08:08:19 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Mon, 8 Mar 2021 08:08:19 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
Message-ID: <68e9211baffa4506bc601f5b8133e75a@EX13D10EUA003.ant.amazon.com>

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 6592165432
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/6592165432
Join via phone (US): +1-929-432-4463,,,6592165432#<tel:+1-929-432-4463,,,6592165432#>
Join via phone (US toll-free): +1-855-552-4463,,,6592165432#<tel:+1-855-552-4463,,,6592165432#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 6592165432#
=================================================




================Before your meeting:================

   *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
   *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
   *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
   *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.
================================================


Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777589627-fandree-1c5b1c7ac9e3d98d02cb97d1a0b6c32c>)



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/ad9dcb3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 5265 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/ad9dcb3a/attachment-0001.ics>

From fandree at amazon.com  Mon Mar  8 08:11:47 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Mon, 8 Mar 2021 08:11:47 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
Message-ID: <a9d203287d324880ab4727d1b3fb681f@EX13D10EUA003.ant.amazon.com>

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 6592165432
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/6592165432
Join via phone (US): +1-929-432-4463,,,6592165432#<tel:+1-929-432-4463,,,6592165432#>
Join via phone (US toll-free): +1-855-552-4463,,,6592165432#<tel:+1-855-552-4463,,,6592165432#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 6592165432#
=================================================




================Before your meeting:================

   *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
   *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
   *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
   *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.
================================================


Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777589627-fandree-1c5b1c7ac9e3d98d02cb97d1a0b6c32c>)



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/897b15fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 5265 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/897b15fa/attachment-0001.ics>

From fandree at amazon.com  Mon Mar  8 10:09:19 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Mon, 8 Mar 2021 10:09:19 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
In-Reply-To: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
References: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
Message-ID: <1615198158689.42580@amazon.com>

Thanks everyone for joining!

​

Here are the meeting minutes:

  *   Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4

  *   whats the idomatic way to do logging across the various crates?

  *   typically people use the log crate and build on top of it: https://crates.io/crates/log

  *   alternative proposal: hide all logging & metrics behind an interface that defines relevant events

  *   example of usage: https://github.com/rust-vmm/vm-superio/blob/c9ecf106d4d8d38fdc8e91e254a7f7890fbe6c60/src/serial.rs#L112

  *   for now this is used only for metrics

  *   CH is using a macro for events: https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_monitor/src/lib.rs

  *   let's use this issue to continue the discussion: https://github.com/rust-vmm/community/issues/104

  *   for debugging & developing we can use the log crate

  *   also an open question about metrics (what/where/how many/how filtered)

  *   Public roadmap for 2021:

  *   https://github.com/orgs/rust-vmm/projects/3

  *   Use label: "roadmap 2021"

  *   Search for roadmap issues: https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=issues

  *   Branching policy for crates and release lifecycle management

  *   we've been doing branch releases for security vulnerabilities

  *   we do not have a policy for releases (how long do we support them)?

  *   QEMU:

  *   dev on master

  *   before releases they're looking more into what gets into master (i.e. only bug fixes)

  *   release branch

  *   3 release/year

  *   CH:

  *   release every 6 weeks

  *   use dependabot

  *   does not support older versions of CH (only support for latest version)

  *   Proposal:

  *   Handle releases on a case by case basis

  *   Proposal for branches: branch when need to (i.e. breaking changes & security releases)

  *   fandree@ add this to the community readme

  *   master support?

  *   only when there is a new change that is needed or when crates are not published

  *   releases on demand to support different projects (release just a versioned tag on master, ad-hoc branch for security backports on a release tag)

  *   obviously master tries to stay stable with CI keeping tests green - cost of a release should be small

  *   kvm-bindings

  *   CH tried to autogenerate new bindings, and it did not work

  *   we need to add documentation (if it does not exist) on how to generate them

  *   State of AArch64 support?

  *   crate support should be complete: kvm-ioctls, linux-loader; used in production Firecracker & Cloud Hypervisor

  *   removing dependency on libfdt options:

  *   rust crate for generating the DT (only static FDT)

  *   ACPI: there is a push to use it by default

  *   adding support to vmm-reference for ARM: https://github.com/rust-vmm/vmm-reference/issues/90

  *   Support for other hypervisors (!KVM):

  *   did not have time to discuss this; we'll discuss it at the next sync meeting


________________________________
From: Florescu, Andreea
Sent: Wednesday, March 3, 2021 3:19 PM
To: Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan; Iordache, Alexandra; Agache, Alexandru; meet at chime.aws; pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org
Cc: M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner; Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid; luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
Subject: rust-vmm sync meeting
When: Monday, March 8, 2021 11:00 AM-12:00 PM.
Where:

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 2352511775
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/2352511775
Join via phone (US): +1-929-432-4463,,,2352511775#<tel:+1-929-432-4463,,,2352511775#>
Join via phone (US toll-free): +1-855-552-4463,,,2352511775#<tel:+1-855-552-4463,,,2352511775#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 2352511775#
=================================================


================Before your meeting:================

  *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
  *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
  *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
  *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.

================================================

Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>)



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/fc02cd01/attachment-0001.html>

From dgreid at google.com  Mon Mar  8 16:19:49 2021
From: dgreid at google.com (Dylan Reid)
Date: Mon, 8 Mar 2021 08:19:49 -0800
Subject: [Rust-VMM] rust-vmm sync meeting
In-Reply-To: <1615198158689.42580@amazon.com>
References: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
 <1615198158689.42580@amazon.com>
Message-ID: <CAEUnVG5GAhFUpzkxYpDTd17Xz9_Zqj=MOvAROLSQj9fT2tWnpA@mail.gmail.com>

On Mon, Mar 8, 2021 at 2:09 AM Florescu, Andreea <fandree at amazon.com> wrote:

> Thanks everyone for joining!
>
>
> Here are the meeting minutes:
>
>    - Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4
>
>
>    - whats the idomatic way to do logging across the various crates?
>
>
>    - typically people use the log crate and build on top of it:
>    https://crates.io/crates/log
>
>
>    - alternative proposal: hide all logging & metrics behind an interface
>    that defines relevant events
>
>
>    - example of usage:
>    https://github.com/rust-vmm/vm-superio/blob/c9ecf106d4d8d38fdc8e91e254a7f7890fbe6c60/src/serial.rs#L112
>
>
>    - for now this is used only for metrics
>
>
>    - CH is using a macro for events:
>    https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_monitor/src/lib.rs
>
>
>    - let's use this issue to continue the discussion:
>    https://github.com/rust-vmm/community/issues/104
>
>
>    - for debugging & developing we can use the log crate
>
>
>    - also an open question about metrics (what/where/how many/how
>    filtered)
>
>
>    - Public roadmap for 2021:
>
>
>    - https://github.com/orgs/rust-vmm/projects/3
>
>
>    - Use label: "roadmap 2021"
>
>
>    - Search for roadmap issues:
>    https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=issues
>
>
>    - Branching policy for crates and release lifecycle management
>
>
>    - we've been doing branch releases for security vulnerabilities
>
>
>    - we do not have a policy for releases (how long do we support them)?
>
>
>    - QEMU:
>
>
>    - dev on master
>
>
>    - before releases they're looking more into what gets into master
>    (i.e. only bug fixes)
>
>
>    - release branch
>
>
>    - 3 release/year
>
>
>    - CH:
>
>
>    - release every 6 weeks
>
>
>    - use dependabot
>
>
>    - does not support older versions of CH (only support for latest
>    version)
>
>
>    - Proposal:
>
>
>    - Handle releases on a case by case basis
>
>
>    - Proposal for branches: branch when need to (i.e. breaking changes &
>    security releases)
>
>
>    - fandree@ add this to the community readme
>
>
>    - master support?
>
>
>    - only when there is a new change that is needed or when crates are
>    not published
>
>
>    - releases on demand to support different projects (release just a
>    versioned tag on master, ad-hoc branch for security backports on a release
>    tag)
>
>
>    - obviously master tries to stay stable with CI keeping tests green -
>    cost of a release should be small
>
>
>    - kvm-bindings
>
>
>    - CH tried to autogenerate new bindings, and it did not work
>
>
>    - we need to add documentation (if it does not exist) on how to
>    generate them
>
>
>    - State of AArch64 support?
>
>
>    - crate support should be complete: kvm-ioctls, linux-loader; used in
>    production Firecracker & Cloud Hypervisor
>
>
>    - removing dependency on libfdt options:
>
>
Daniel started cleaning up the FDT implementation in crosvm recently:
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569
That might be a good starting point. It still has some work to do IIRC. If
it looks useful, we can move it to a separate crate as it's currently in
that aarch64 code.


>    - rust crate for generating the DT (only static FDT)
>
>
>    - ACPI: there is a push to use it by default
>
>
>    - adding support to vmm-reference for ARM:
>    https://github.com/rust-vmm/vmm-reference/issues/90
>
>
>    - Support for other hypervisors (!KVM):
>
>
>    - did not have time to discuss this; we'll discuss it at the next sync
>    meeting
>
>
> ------------------------------
> *From:* Florescu, Andreea
> *Sent:* Wednesday, March 3, 2021 3:19 PM
> *To:* Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan;
> Iordache, Alexandra; Agache, Alexandru; meet at chime.aws;
> pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org
> *Cc:* M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner;
> Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid;
> luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
> *Subject:* rust-vmm sync meeting
> *When:* Monday, March 8, 2021 11:00 AM-12:00 PM.
> *Where:*
>
> Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
> ==============Conference Bridge Information==============
> You have been invited to an online meeting, powered by Amazon Chime.
> *Chime meeting ID: 2352511775*
> *Join via Chime clients (manually): Select 'Meetings > Join a Meeting',
> and enter 2352511775*
> *Join via Chime clients (auto-call): If you invite auto-call as attendee,
> Chime will call you when the meeting starts, select 'Answer'*
> *Join via browser screen share: https://chime.aws/2352511775
> <https://chime.aws/2352511775>*
> *Join via phone (US): +1-929-432-4463,,,2352511775#
> <+1-929-432-4463,,,2352511775#>*
> *Join via phone (US toll-free): +1-855-552-4463,,,2352511775#
> <+1-855-552-4463,,,2352511775#>*
> *International dial-in: https://chime.aws/dialinnumbers/
> <https://chime.aws/dialinnumbers/>*
> *In-room video system: Ext: 62000, Meeting PIN: 2352511775#*
> =================================================
>
>
> ================Before your meeting:================
>
>    - Learn how to use the touch panel
>    <https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
>
>    - Prefer a video? Watch these touch panel how-to videos
>    <https://broadcast.amazon.com/videos/98363>.
>    - Find out more about room layouts
>    <https://it.amazon.com/en/help/articles/conference-room-configurations>.
>
>    - Get more information at it.amazon.com/meetings
>    <https://it.amazon.com/en/servicecatalog/meetings>.
>
> ================================================
>
> Created with Amazon Meetings <https://meetings.amazon.com> (fandree@, edit
> this series
> <https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>
> )
>
>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered
> in Romania. Registration number J22/2621/2005.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/6b4900ca/attachment-0001.html>

From dverkamp at chromium.org  Mon Mar  8 22:59:14 2021
From: dverkamp at chromium.org (Daniel Verkamp)
Date: Mon, 8 Mar 2021 14:59:14 -0800
Subject: [Rust-VMM] rust-vmm sync meeting
In-Reply-To: <CAEUnVG5GAhFUpzkxYpDTd17Xz9_Zqj=MOvAROLSQj9fT2tWnpA@mail.gmail.com>
References: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
 <1615198158689.42580@amazon.com>
 <CAEUnVG5GAhFUpzkxYpDTd17Xz9_Zqj=MOvAROLSQj9fT2tWnpA@mail.gmail.com>
Message-ID: <CABVzXAm3mPmUR5VKcVDAfZ7Q0c_D9i=SJeXMCYXzm+cgCUf3Wg@mail.gmail.com>

The core of the Rust FDT interface mentioned by Dylan is here:
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569/8/arch/src/fdt.rs

I intentionally avoided any dependencies on external crates (except
thiserror, which could easily be eliminated if desired), so it should be
easy to extract it into its own crate.

It is functionally complete (for the functionality needed in crosvm, at
least) - I have some related work in progress to read the host system's
devicetree from the kernel, but that should not be necessary for most use
cases.

The API was designed to be similar to the C libfdt API to make it easy to
replace our existing usage, but if it's going to be used outside crosvm, it
would be good to get feedback from potential users on the design - please
take a look if you're interested.


On Mon, Mar 8, 2021 at 8:20 AM Dylan Reid <dgreid at google.com> wrote:

>
>
> On Mon, Mar 8, 2021 at 2:09 AM Florescu, Andreea <fandree at amazon.com>
> wrote:
>
>> Thanks everyone for joining!
>>
>>
>> Here are the meeting minutes:
>>
>>    - Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4
>>
>>
>>    - whats the idomatic way to do logging across the various crates?
>>
>>
>>    - typically people use the log crate and build on top of it:
>>    https://crates.io/crates/log
>>
>>
>>    - alternative proposal: hide all logging & metrics behind an
>>    interface that defines relevant events
>>
>>
>>    - example of usage:
>>    https://github.com/rust-vmm/vm-superio/blob/c9ecf106d4d8d38fdc8e91e254a7f7890fbe6c60/src/serial.rs#L112
>>
>>
>>    - for now this is used only for metrics
>>
>>
>>    - CH is using a macro for events:
>>    https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_monitor/src/lib.rs
>>
>>
>>    - let's use this issue to continue the discussion:
>>    https://github.com/rust-vmm/community/issues/104
>>
>>
>>    - for debugging & developing we can use the log crate
>>
>>
>>    - also an open question about metrics (what/where/how many/how
>>    filtered)
>>
>>
>>    - Public roadmap for 2021:
>>
>>
>>    - https://github.com/orgs/rust-vmm/projects/3
>>
>>
>>    - Use label: "roadmap 2021"
>>
>>
>>    - Search for roadmap issues:
>>    https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=issues
>>
>>
>>    - Branching policy for crates and release lifecycle management
>>
>>
>>    - we've been doing branch releases for security vulnerabilities
>>
>>
>>    - we do not have a policy for releases (how long do we support them)?
>>
>>
>>    - QEMU:
>>
>>
>>    - dev on master
>>
>>
>>    - before releases they're looking more into what gets into master
>>    (i.e. only bug fixes)
>>
>>
>>    - release branch
>>
>>
>>    - 3 release/year
>>
>>
>>    - CH:
>>
>>
>>    - release every 6 weeks
>>
>>
>>    - use dependabot
>>
>>
>>    - does not support older versions of CH (only support for latest
>>    version)
>>
>>
>>    - Proposal:
>>
>>
>>    - Handle releases on a case by case basis
>>
>>
>>    - Proposal for branches: branch when need to (i.e. breaking changes &
>>    security releases)
>>
>>
>>    - fandree@ add this to the community readme
>>
>>
>>    - master support?
>>
>>
>>    - only when there is a new change that is needed or when crates are
>>    not published
>>
>>
>>    - releases on demand to support different projects (release just a
>>    versioned tag on master, ad-hoc branch for security backports on a release
>>    tag)
>>
>>
>>    - obviously master tries to stay stable with CI keeping tests green -
>>    cost of a release should be small
>>
>>
>>    - kvm-bindings
>>
>>
>>    - CH tried to autogenerate new bindings, and it did not work
>>
>>
>>    - we need to add documentation (if it does not exist) on how to
>>    generate them
>>
>>
>>    - State of AArch64 support?
>>
>>
>>    - crate support should be complete: kvm-ioctls, linux-loader; used in
>>    production Firecracker & Cloud Hypervisor
>>
>>
>>    - removing dependency on libfdt options:
>>
>>
> Daniel started cleaning up the FDT implementation in crosvm recently:
> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569
> That might be a good starting point. It still has some work to do IIRC. If
> it looks useful, we can move it to a separate crate as it's currently in
> that aarch64 code.
>
>
>>    - rust crate for generating the DT (only static FDT)
>>
>>
>>    - ACPI: there is a push to use it by default
>>
>>
>>    - adding support to vmm-reference for ARM:
>>    https://github.com/rust-vmm/vmm-reference/issues/90
>>
>>
>>    - Support for other hypervisors (!KVM):
>>
>>
>>    - did not have time to discuss this; we'll discuss it at the next
>>    sync meeting
>>
>>
>> ------------------------------
>> *From:* Florescu, Andreea
>> *Sent:* Wednesday, March 3, 2021 3:19 PM
>> *To:* Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan;
>> Iordache, Alexandra; Agache, Alexandru; meet at chime.aws;
>> pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org
>> *Cc:* M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner;
>> Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid;
>> luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
>> *Subject:* rust-vmm sync meeting
>> *When:* Monday, March 8, 2021 11:00 AM-12:00 PM.
>> *Where:*
>>
>> Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
>> ==============Conference Bridge Information==============
>> You have been invited to an online meeting, powered by Amazon Chime.
>> *Chime meeting ID: 2352511775*
>> *Join via Chime clients (manually): Select 'Meetings > Join a Meeting',
>> and enter 2352511775*
>> *Join via Chime clients (auto-call): If you invite auto-call as attendee,
>> Chime will call you when the meeting starts, select 'Answer'*
>> *Join via browser screen share: https://chime.aws/2352511775
>> <https://chime.aws/2352511775>*
>> *Join via phone (US): +1-929-432-4463,,,2352511775#
>> <+1-929-432-4463,,,2352511775#>*
>> *Join via phone (US toll-free): +1-855-552-4463,,,2352511775#
>> <+1-855-552-4463,,,2352511775#>*
>> *International dial-in: https://chime.aws/dialinnumbers/
>> <https://chime.aws/dialinnumbers/>*
>> *In-room video system: Ext: 62000, Meeting PIN: 2352511775#*
>> =================================================
>>
>>
>> ================Before your meeting:================
>>
>>    - Learn how to use the touch panel
>>    <https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
>>
>>    - Prefer a video? Watch these touch panel how-to videos
>>    <https://broadcast.amazon.com/videos/98363>.
>>    - Find out more about room layouts
>>    <https://it.amazon.com/en/help/articles/conference-room-configurations>.
>>
>>    - Get more information at it.amazon.com/meetings
>>    <https://it.amazon.com/en/servicecatalog/meetings>.
>>
>> ================================================
>>
>> Created with Amazon Meetings <https://meetings.amazon.com> (fandree@, edit
>> this series
>> <https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>
>> )
>>
>>
>> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
>> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered
>> in Romania. Registration number J22/2621/2005.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210308/ba116f85/attachment-0001.html>

From fandree at amazon.com  Tue Mar  9 10:34:48 2021
From: fandree at amazon.com (Florescu, Andreea)
Date: Tue, 9 Mar 2021 10:34:48 +0000
Subject: [Rust-VMM] rust-vmm sync meeting
In-Reply-To: <CABVzXAm3mPmUR5VKcVDAfZ7Q0c_D9i=SJeXMCYXzm+cgCUf3Wg@mail.gmail.com>
References: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
 <1615198158689.42580@amazon.com>
 <CAEUnVG5GAhFUpzkxYpDTd17Xz9_Zqj=MOvAROLSQj9fT2tWnpA@mail.gmail.com>,
 <CABVzXAm3mPmUR5VKcVDAfZ7Q0c_D9i=SJeXMCYXzm+cgCUf3Wg@mail.gmail.com>
Message-ID: <1615286087817.79209@amazon.com>

​That's super nice!

We can do some experiments and check if the FDT crate from crosvm also works in Firecracker and Cloud Hypervisor.


Would you be interested in having fdt as a rust-vmm crate? If yes, we can open an issue and discuss about the design there.


Thanks,

Andreea

________________________________
From: Daniel Verkamp <dverkamp at chromium.org>
Sent: Tuesday, March 9, 2021 12:59 AM
To: Dylan Reid
Cc: Florescu, Andreea; Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan; Iordache, Alexandra; Agache, Alexandru; meet at chime.aws; pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org; M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner; Wise, Bob; Liguori, Anthony; Trilok Soni; luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
Subject: RE: [EXTERNAL] rust-vmm sync meeting


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


The core of the Rust FDT interface mentioned by Dylan is here: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569/8/arch/src/fdt.rs

I intentionally avoided any dependencies on external crates (except thiserror, which could easily be eliminated if desired), so it should be easy to extract it into its own crate.

It is functionally complete (for the functionality needed in crosvm, at least) - I have some related work in progress to read the host system's devicetree from the kernel, but that should not be necessary for most use cases.

The API was designed to be similar to the C libfdt API to make it easy to replace our existing usage, but if it's going to be used outside crosvm, it would be good to get feedback from potential users on the design - please take a look if you're interested.


On Mon, Mar 8, 2021 at 8:20 AM Dylan Reid <dgreid at google.com<mailto:dgreid at google.com>> wrote:


On Mon, Mar 8, 2021 at 2:09 AM Florescu, Andreea <fandree at amazon.com<mailto:fandree at amazon.com>> wrote:

Thanks everyone for joining!


Here are the meeting minutes:

  *   Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4

  *   whats the idomatic way to do logging across the various crates?

  *   typically people use the log crate and build on top of it: https://crates.io/crates/log

  *   alternative proposal: hide all logging & metrics behind an interface that defines relevant events

  *   example of usage: https://github.com/rust-vmm/vm-superio/blob/c9ecf106d4d8d38fdc8e91e254a7f7890fbe6c60/src/serial.rs#L112

  *   for now this is used only for metrics

  *   CH is using a macro for events: https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_monitor/src/lib.rs

  *   let's use this issue to continue the discussion: https://github.com/rust-vmm/community/issues/104

  *   for debugging & developing we can use the log crate

  *   also an open question about metrics (what/where/how many/how filtered)

  *   Public roadmap for 2021:

  *   https://github.com/orgs/rust-vmm/projects/3

  *   Use label: "roadmap 2021"

  *   Search for roadmap issues: https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=issues

  *   Branching policy for crates and release lifecycle management

  *   we've been doing branch releases for security vulnerabilities

  *   we do not have a policy for releases (how long do we support them)?

  *   QEMU:

  *   dev on master

  *   before releases they're looking more into what gets into master (i.e. only bug fixes)

  *   release branch

  *   3 release/year

  *   CH:

  *   release every 6 weeks

  *   use dependabot

  *   does not support older versions of CH (only support for latest version)

  *   Proposal:

  *   Handle releases on a case by case basis

  *   Proposal for branches: branch when need to (i.e. breaking changes & security releases)

  *   fandree@ add this to the community readme

  *   master support?

  *   only when there is a new change that is needed or when crates are not published

  *   releases on demand to support different projects (release just a versioned tag on master, ad-hoc branch for security backports on a release tag)

  *   obviously master tries to stay stable with CI keeping tests green - cost of a release should be small

  *   kvm-bindings

  *   CH tried to autogenerate new bindings, and it did not work

  *   we need to add documentation (if it does not exist) on how to generate them

  *   State of AArch64 support?

  *   crate support should be complete: kvm-ioctls, linux-loader; used in production Firecracker & Cloud Hypervisor

  *   removing dependency on libfdt options:

Daniel started cleaning up the FDT implementation in crosvm recently: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569
That might be a good starting point. It still has some work to do IIRC. If it looks useful, we can move it to a separate crate as it's currently in that aarch64 code.


  *   rust crate for generating the DT (only static FDT)

  *   ACPI: there is a push to use it by default

  *   adding support to vmm-reference for ARM: https://github.com/rust-vmm/vmm-reference/issues/90

  *   Support for other hypervisors (!KVM):

  *   did not have time to discuss this; we'll discuss it at the next sync meeting


________________________________
From: Florescu, Andreea
Sent: Wednesday, March 3, 2021 3:19 PM
To: Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan; Iordache, Alexandra; Agache, Alexandru; meet at chime.aws; pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org<mailto:rust-vmm at lists.opendev.org>
Cc: M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner; Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid; luka.perkov at sartura.hr<mailto:luka.perkov at sartura.hr>; Brendan Burns; Alex Bennée
Subject: rust-vmm sync meeting
When: Monday, March 8, 2021 11:00 AM-12:00 PM.
Where:

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
==============Conference Bridge Information==============
You have been invited to an online meeting, powered by Amazon Chime.
Chime meeting ID: 2352511775
Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775
Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer'
Join via browser screen share: https://chime.aws/2352511775
Join via phone (US): +1-929-432-4463,,,2352511775#<tel:+1-929-432-4463,,,2352511775#>
Join via phone (US toll-free): +1-855-552-4463,,,2352511775#<tel:+1-855-552-4463,,,2352511775#>
International dial-in: https://chime.aws/dialinnumbers/
In-room video system: Ext: 62000, Meeting PIN: 2352511775#
=================================================


================Before your meeting:================

  *   Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
  *   Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>.
  *   Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>.
  *   Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>.

================================================

Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>)

Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210309/eb06923a/attachment-0001.html>

From dverkamp at chromium.org  Tue Mar  9 21:57:03 2021
From: dverkamp at chromium.org (Daniel Verkamp)
Date: Tue, 9 Mar 2021 13:57:03 -0800
Subject: [Rust-VMM] rust-vmm sync meeting
In-Reply-To: <1615286087817.79209@amazon.com>
References: <87ac5633b6b74e47a4f933b9e5b46d72@EX13D10EUA003.ant.amazon.com>
 <1615198158689.42580@amazon.com>
 <CAEUnVG5GAhFUpzkxYpDTd17Xz9_Zqj=MOvAROLSQj9fT2tWnpA@mail.gmail.com>
 <CABVzXAm3mPmUR5VKcVDAfZ7Q0c_D9i=SJeXMCYXzm+cgCUf3Wg@mail.gmail.com>
 <1615286087817.79209@amazon.com>
Message-ID: <CABVzXAk0ZvyNjcQUOV7nkepn0+y5gBWsbRBiK0SiLa+UXTTD4A@mail.gmail.com>

Yes, that sounds good - I just noticed that there is an existing issue for
a vmm-fdt crate, so we can coordinate there:
https://github.com/rust-vmm/community/issues/87

Thanks,
-- Daniel

On Tue, Mar 9, 2021 at 2:35 AM Florescu, Andreea <fandree at amazon.com> wrote:

> ​That's super nice!
>
> We can do some experiments and check if the FDT crate from crosvm also
> works in Firecracker and Cloud Hypervisor.
>
>
> Would you be interested in having fdt as a rust-vmm crate? If yes, we can
> open an issue and discuss about the design there.
>
>
> Thanks,
>
> Andreea
> ------------------------------
> *From:* Daniel Verkamp <dverkamp at chromium.org>
> *Sent:* Tuesday, March 9, 2021 12:59 AM
> *To:* Dylan Reid
> *Cc:* Florescu, Andreea; Barbu, Iulian; Loghin, Laura; Ochescu, Catalin;
> Horobeanu, Dan; Iordache, Alexandra; Agache, Alexandru; meet at chime.aws;
> pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org; M. Dodson; Ceyhun
> Ertürk; Catangiu, Adrian Costin; Zach Reizner; Wise, Bob; Liguori, Anthony;
> Trilok Soni; luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
> *Subject:* RE: [EXTERNAL] rust-vmm sync meeting
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> The core of the Rust FDT interface mentioned by Dylan is here:
> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569/8/arch/src/fdt.rs
>
> I intentionally avoided any dependencies on external crates (except
> thiserror, which could easily be eliminated if desired), so it should be
> easy to extract it into its own crate.
>
> It is functionally complete (for the functionality needed in crosvm, at
> least) - I have some related work in progress to read the host system's
> devicetree from the kernel, but that should not be necessary for most use
> cases.
>
> The API was designed to be similar to the C libfdt API to make it easy to
> replace our existing usage, but if it's going to be used outside crosvm, it
> would be good to get feedback from potential users on the design - please
> take a look if you're interested.
>
>
> On Mon, Mar 8, 2021 at 8:20 AM Dylan Reid <dgreid at google.com> wrote:
>
>>
>>
>> On Mon, Mar 8, 2021 at 2:09 AM Florescu, Andreea <fandree at amazon.com>
>> wrote:
>>
>>> Thanks everyone for joining!
>>>
>>>
>>> Here are the meeting minutes:
>>>
>>>    - Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4
>>>
>>>
>>>    - whats the idomatic way to do logging across the various crates?
>>>
>>>
>>>    - typically people use the log crate and build on top of it:
>>>    https://crates.io/crates/log
>>>
>>>
>>>    - alternative proposal: hide all logging & metrics behind an
>>>    interface that defines relevant events
>>>
>>>
>>>    - example of usage:
>>>    https://github.com/rust-vmm/vm-superio/blob/c9ecf106d4d8d38fdc8e91e254a7f7890fbe6c60/src/serial.rs#L112
>>>
>>>
>>>    - for now this is used only for metrics
>>>
>>>
>>>    - CH is using a macro for events:
>>>    https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_monitor/src/lib.rs
>>>
>>>
>>>    - let's use this issue to continue the discussion:
>>>    https://github.com/rust-vmm/community/issues/104
>>>
>>>
>>>    - for debugging & developing we can use the log crate
>>>
>>>
>>>    - also an open question about metrics (what/where/how many/how
>>>    filtered)
>>>
>>>
>>>    - Public roadmap for 2021:
>>>
>>>
>>>    - https://github.com/orgs/rust-vmm/projects/3
>>>
>>>
>>>    - Use label: "roadmap 2021"
>>>
>>>
>>>    - Search for roadmap issues:
>>>    https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=issues
>>>
>>>
>>>    - Branching policy for crates and release lifecycle management
>>>
>>>
>>>    - we've been doing branch releases for security vulnerabilities
>>>
>>>
>>>    - we do not have a policy for releases (how long do we support them)?
>>>
>>>
>>>    - QEMU:
>>>
>>>
>>>    - dev on master
>>>
>>>
>>>    - before releases they're looking more into what gets into master
>>>    (i.e. only bug fixes)
>>>
>>>
>>>    - release branch
>>>
>>>
>>>    - 3 release/year
>>>
>>>
>>>    - CH:
>>>
>>>
>>>    - release every 6 weeks
>>>
>>>
>>>    - use dependabot
>>>
>>>
>>>    - does not support older versions of CH (only support for latest
>>>    version)
>>>
>>>
>>>    - Proposal:
>>>
>>>
>>>    - Handle releases on a case by case basis
>>>
>>>
>>>    - Proposal for branches: branch when need to (i.e. breaking changes
>>>    & security releases)
>>>
>>>
>>>    - fandree@ add this to the community readme
>>>
>>>
>>>    - master support?
>>>
>>>
>>>    - only when there is a new change that is needed or when crates are
>>>    not published
>>>
>>>
>>>    - releases on demand to support different projects (release just a
>>>    versioned tag on master, ad-hoc branch for security backports on a release
>>>    tag)
>>>
>>>
>>>    - obviously master tries to stay stable with CI keeping tests green
>>>    - cost of a release should be small
>>>
>>>
>>>    - kvm-bindings
>>>
>>>
>>>    - CH tried to autogenerate new bindings, and it did not work
>>>
>>>
>>>    - we need to add documentation (if it does not exist) on how to
>>>    generate them
>>>
>>>
>>>    - State of AArch64 support?
>>>
>>>
>>>    - crate support should be complete: kvm-ioctls, linux-loader; used
>>>    in production Firecracker & Cloud Hypervisor
>>>
>>>
>>>    - removing dependency on libfdt options:
>>>
>>>
>> Daniel started cleaning up the FDT implementation in crosvm recently:
>> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569
>> That might be a good starting point. It still has some work to do IIRC.
>> If it looks useful, we can move it to a separate crate as it's currently in
>> that aarch64 code.
>>
>>
>>>    - rust crate for generating the DT (only static FDT)
>>>
>>>
>>>    - ACPI: there is a push to use it by default
>>>
>>>
>>>    - adding support to vmm-reference for ARM:
>>>    https://github.com/rust-vmm/vmm-reference/issues/90
>>>
>>>
>>>    - Support for other hypervisors (!KVM):
>>>
>>>
>>>    - did not have time to discuss this; we'll discuss it at the next
>>>    sync meeting
>>>
>>>
>>> ------------------------------
>>> *From:* Florescu, Andreea
>>> *Sent:* Wednesday, March 3, 2021 3:19 PM
>>> *To:* Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan;
>>> Iordache, Alexandra; Agache, Alexandru; meet at chime.aws;
>>> pin+2352511775 at chime.aws; rust-vmm at lists.opendev.org
>>> *Cc:* M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner;
>>> Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid;
>>> luka.perkov at sartura.hr; Brendan Burns; Alex Bennée
>>> *Subject:* rust-vmm sync meeting
>>> *When:* Monday, March 8, 2021 11:00 AM-12:00 PM.
>>> *Where:*
>>>
>>> Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021
>>> ==============Conference Bridge Information==============
>>> You have been invited to an online meeting, powered by Amazon Chime.
>>> *Chime meeting ID: 2352511775*
>>> *Join via Chime clients (manually): Select 'Meetings > Join a Meeting',
>>> and enter 2352511775*
>>> *Join via Chime clients (auto-call): If you invite auto-call as
>>> attendee, Chime will call you when the meeting starts, select 'Answer'*
>>> *Join via browser screen share: https://chime.aws/2352511775
>>> <https://chime.aws/2352511775>*
>>> *Join via phone (US): +1-929-432-4463,,,2352511775#
>>> <+1-929-432-4463,,,2352511775#>*
>>> *Join via phone (US toll-free): +1-855-552-4463,,,2352511775#
>>> <+1-855-552-4463,,,2352511775#>*
>>> *International dial-in: https://chime.aws/dialinnumbers/
>>> <https://chime.aws/dialinnumbers/>*
>>> *In-room video system: Ext: 62000, Meeting PIN: 2352511775#*
>>> =================================================
>>>
>>>
>>> ================Before your meeting:================
>>>
>>>    - Learn how to use the touch panel
>>>    <https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>.
>>>
>>>    - Prefer a video? Watch these touch panel how-to videos
>>>    <https://broadcast.amazon.com/videos/98363>.
>>>    - Find out more about room layouts
>>>    <https://it.amazon.com/en/help/articles/conference-room-configurations>.
>>>
>>>    - Get more information at it.amazon.com/meetings
>>>    <https://it.amazon.com/en/servicecatalog/meetings>.
>>>
>>> ================================================
>>>
>>> Created with Amazon Meetings <https://meetings.amazon.com> (fandree@, edit
>>> this series
>>> <https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fandree-ef276bd02425fd937ae7c9d0a2756544>
>>> )
>>>
>>>
>>> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
>>> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered
>>> in Romania. Registration number J22/2621/2005.
>>>
>>
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered
> in Romania. Registration number J22/2621/2005.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210309/4f506e6e/attachment-0001.html>

From slp at redhat.com  Tue Mar 16 16:27:50 2021
From: slp at redhat.com (Sergio Lopez)
Date: Tue, 16 Mar 2021 17:27:50 +0100
Subject: [Rust-VMM] Hosting vhost-user servers in rust-vmm?
Message-ID: <20210316162750.ltfbt4hrzlxwv7eh@mhamilton>

Hi,

It's very likely that, along this year, we'll start seeing a number of
new vhost-user device implementations based on rust-vmm crates.

I think it'd be very valuable to have a centralized place to host
those crates, so both final users and developers can easily find them,
and I have the feeling that rust-vmm can be that place.

Do you think rust-vmm is the right place for them? Would we need to
update the Community docs to reflect the presence of such components?

Thanks,
Sergio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210316/bea89717/attachment.sig>

From samuel.ortiz at intel.com  Tue Mar 16 16:37:00 2021
From: samuel.ortiz at intel.com (Samuel Ortiz)
Date: Tue, 16 Mar 2021 17:37:00 +0100
Subject: [Rust-VMM] Hosting vhost-user servers in rust-vmm?
In-Reply-To: <20210316162750.ltfbt4hrzlxwv7eh@mhamilton>
References: <20210316162750.ltfbt4hrzlxwv7eh@mhamilton>
Message-ID: <YFDerEZO9fCduT6g@sortiz-mobl1.home>

Hi Sergio,

On Tue, Mar 16, 2021 at 05:27:50PM +0100, Sergio Lopez wrote:
> Hi,
> 
> It's very likely that, along this year, we'll start seeing a number of
> new vhost-user device implementations based on rust-vmm crates.
> 
> I think it'd be very valuable to have a centralized place to host
> those crates, so both final users and developers can easily find them,
> and I have the feeling that rust-vmm can be that place.
It would make sense, yes.


> Do you think rust-vmm is the right place for them?
Yes.


> Would we need to
> update the Community docs to reflect the presence of such components?
What do you think should be updated? The fact that we're not only
hosting crates? If that's the case, there's already a precedent with the
vmm-reference, so I don't think this is a mandatory step.

Cheers,
Samuel.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



From liuj97 at gmail.com  Wed Mar 17 04:19:06 2021
From: liuj97 at gmail.com (Jiang Liu)
Date: Wed, 17 Mar 2021 12:19:06 +0800
Subject: [Rust-VMM] Hosting vhost-user servers in rust-vmm?
In-Reply-To: <YFDerEZO9fCduT6g@sortiz-mobl1.home>
References: <20210316162750.ltfbt4hrzlxwv7eh@mhamilton>
 <YFDerEZO9fCduT6g@sortiz-mobl1.home>
Message-ID: <83A51EDC-74F5-4057-9274-D0740B5BE189@gmail.com>



> On Mar 17, 2021, at 12:37 AM, Samuel Ortiz <samuel.ortiz at intel.com> wrote:
> 
> Hi Sergio,
> 
> On Tue, Mar 16, 2021 at 05:27:50PM +0100, Sergio Lopez wrote:
>> Hi,
>> 
>> It's very likely that, along this year, we'll start seeing a number of
>> new vhost-user device implementations based on rust-vmm crates.
>> 
>> I think it'd be very valuable to have a centralized place to host
>> those crates, so both final users and developers can easily find them,
>> and I have the feeling that rust-vmm can be that place.
> It would make sense, yes.
Welcome！

> 
> 
>> Do you think rust-vmm is the right place for them?
> Yes.
> 
> 
>> Would we need to
>> update the Community docs to reflect the presence of such components?
> What do you think should be updated? The fact that we're not only
> hosting crates? If that's the case, there's already a precedent with the
> vmm-reference, so I don't think this is a mandatory step.
It’s two years since birth, it’s a chance for evolution now:)

> 
> Cheers,
> Samuel.
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris, 
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm



From kennelson11 at gmail.com  Tue Mar 23 16:14:38 2021
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 23 Mar 2021 09:14:38 -0700
Subject: [Rust-VMM] vPTG April 2021 Team Signup
Message-ID: <CAJ6yrQhx5BdDJJ1ELpjs9_jsq8BnZYFxveS=VQPEE9b4jfw=qQ@mail.gmail.com>

Greetings!

As you hopefully already know, our next PTG will be virtual again, and held
from Monday, April 19 to Friday, April 23. We will have the same schedule
set up available as last time with three windows of time spread across the
day to cover all timezones with breaks in between.

To signup your team, you must complete BOTH the survey[1] AND reserve time
in the ethercalc[2] by March 25 at 7:00 UTC.

We ask that the PTL/SIG Chair/Team lead sign up for time to have their
discussions in with 4 rules/guidelines.

1. Cross project discussions (like SIGs or support project teams) should be
scheduled towards the start of the week so that any discussions that might
shape those of other teams happen first.
2. No team should sign up for more than 4 hours per UTC day to help keep
participants actively engaged.
3. No team should sign up for more than 16 hours across all time slots to
avoid burning out our contributors and to enable participation in multiple
teams discussions.

Again, you need to fill out BOTH the ethercalc AND the survey to complete
your team's sign up.

If you have any issues with signing up your team, due to conflict or
otherwise, please let me know! While we are trying to empower you to make
your own decisions as to when you meet and for how long (after all, you
know your needs and teams timezones better than we do), we are here to help!

Once your team is signed up, please register! And remind your team to
register! Registration is free, but since it will be how we contact you
with passwords, event details, etc. it is still important!

Continue to check back for updates at openstack.org/ptg.

-the Kendalls (diablo_rojo & wendallkaters)


[1] Team Survey:
https://openinfrafoundation.formstack.com/forms/april2021_vptg_survey
[2] Ethercalc Signup: https://ethercalc.net/oz7q0gds9zfi
[3] PTG Registration: https://april2021-ptg.eventbrite.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210323/5f8ad9a6/attachment.html>