[virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Damir Shaikhutdinov]

Hello!

While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
some additional clarification regarding handling requests when it was offered.

This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".

5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."

5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.

5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
feature if offered, and MUST NOT write any data."

What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:

* config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
* VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
* VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
* VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)

Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.

This can be clarified in several ways, for example:

1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.


What do you think about that?

With best regards,
Damir Shaikhutdinov

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Michael S. Tsirkin]

On Mon, Jan 20, 2020 at 11:45:05AM +0000, Damir Shaikhutdinov wrote:
> Hello!
> 
> While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
> some additional clarification regarding handling requests when it was offered.
> 
> This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".
> 
> 5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."
> 
> 5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.
> 
> 5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
> feature if offered, and MUST NOT write any data."
> 
> What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:
> 
> * config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
> * VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
> * VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
> * VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)
> 
> Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.
> 
> This can be clarified in several ways, for example:
> 
> 1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
> 2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.
> 
> 
> What do you think about that?

I guess flush can even be allowed, it's harmless if nothing is written,
right? I agree DISCARD and WRITE_ZEROES must fail. And set VIRTIO_BLK_S_IOERR
I guess?

It's too late to disallow configurations such as a combination of VIRTIO_BLK_F_CONFIG_WCE
and VIRTIO_BLK_F_RO, devices out there might be setting this combination.

> With best regards,
> Damir Shaikhutdinov
> 
> Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>
> 
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

On Mon, Jan 20, 2020 at 11:21:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 20, 2020 at 11:45:05AM +0000, Damir Shaikhutdinov wrote:
> > Hello!
> > 
> > While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
> > some additional clarification regarding handling requests when it was offered.
> > 
> > This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".
> > 
> > 5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."
> > 
> > 5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.
> > 
> > 5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
> > feature if offered, and MUST NOT write any data."
> > 
> > What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:
> > 
> > * config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
> > * VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
> > * VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
> > * VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)
> > 
> > Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.
> > 
> > This can be clarified in several ways, for example:
> > 
> > 1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
> > 2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.
> > 
> > 
> > What do you think about that?
> 
> I guess flush can even be allowed, it's harmless if nothing is written,
> right?

I agree.  There seems to be no benefit in failing it and there's a small
chance that some drivers could get upset if it fails (typically when a
common code path submits a flush request and expects it to succeed).

> I agree DISCARD and WRITE_ZEROES must fail. And set VIRTIO_BLK_S_IOERR
> I guess?

Yes.

> It's too late to disallow configurations such as a combination of VIRTIO_BLK_F_CONFIG_WCE
> and VIRTIO_BLK_F_RO, devices out there might be setting this combination.

Yes.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Michael S. Tsirkin]

On Tue, Jan 21, 2020 at 04:08:18PM +0000, Stefan Hajnoczi wrote:
> On Mon, Jan 20, 2020 at 11:21:36AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 20, 2020 at 11:45:05AM +0000, Damir Shaikhutdinov wrote:
> > > Hello!
> > > 
> > > While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
> > > some additional clarification regarding handling requests when it was offered.
> > > 
> > > This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".
> > > 
> > > 5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."
> > > 
> > > 5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.
> > > 
> > > 5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
> > > feature if offered, and MUST NOT write any data."
> > > 
> > > What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:
> > > 
> > > * config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
> > > * VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
> > > * VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
> > > * VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)
> > > 
> > > Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.
> > > 
> > > This can be clarified in several ways, for example:
> > > 
> > > 1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
> > > 2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.
> > > 
> > > 
> > > What do you think about that?
> > 
> > I guess flush can even be allowed, it's harmless if nothing is written,
> > right?
> 
> I agree.  There seems to be no benefit in failing it and there's a small
> chance that some drivers could get upset if it fails (typically when a
> common code path submits a flush request and expects it to succeed).
> 
> > I agree DISCARD and WRITE_ZEROES must fail. And set VIRTIO_BLK_S_IOERR
> > I guess?
> 
> Yes.
> 
> > It's too late to disallow configurations such as a combination of VIRTIO_BLK_F_CONFIG_WCE
> > and VIRTIO_BLK_F_RO, devices out there might be setting this combination.
> 
> Yes.
> 
> Stefan

Thanks! Stefan do you have the time to work on a spec patch to fix this?
Damir do you?

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/

Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Wed, Jan 22, 2020 at 12:53:37AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 21, 2020 at 04:08:18PM +0000, Stefan Hajnoczi wrote:
> > On Mon, Jan 20, 2020 at 11:21:36AM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 20, 2020 at 11:45:05AM +0000, Damir Shaikhutdinov wrote:
> > > > Hello!
> > > > 
> > > > While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
> > > > some additional clarification regarding handling requests when it was offered.
> > > > 
> > > > This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".
> > > > 
> > > > 5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."
> > > > 
> > > > 5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.
> > > > 
> > > > 5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
> > > > feature if offered, and MUST NOT write any data."
> > > > 
> > > > What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:
> > > > 
> > > > * config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
> > > > * VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
> > > > * VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
> > > > * VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)
> > > > 
> > > > Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.
> > > > 
> > > > This can be clarified in several ways, for example:
> > > > 
> > > > 1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
> > > > 2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.
> > > > 
> > > > 
> > > > What do you think about that?
> > > 
> > > I guess flush can even be allowed, it's harmless if nothing is written,
> > > right?
> > 
> > I agree.  There seems to be no benefit in failing it and there's a small
> > chance that some drivers could get upset if it fails (typically when a
> > common code path submits a flush request and expects it to succeed).
> > 
> > > I agree DISCARD and WRITE_ZEROES must fail. And set VIRTIO_BLK_S_IOERR
> > > I guess?
> > 
> > Yes.
> > 
> > > It's too late to disallow configurations such as a combination of VIRTIO_BLK_F_CONFIG_WCE
> > > and VIRTIO_BLK_F_RO, devices out there might be setting this combination.
> > 
> > Yes.
> > 
> > Stefan
> 
> Thanks! Stefan do you have the time to work on a spec patch to fix this?
> Damir do you?

Damir, you can find instructions for contributing to the virtio
specification here:

https://github.com/oasis-tcs/virtio-spec/

If you don't have time to write a patch please let me know.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

[Damir Shaikhutdinov]

Hi Stefan and Michael!

I have time to prepare the spec patch and will work on it.

Damir Shaikhutdinov
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0.
Fax:      +49 30 60 98 54 0 -99
EMail:   damir.shaikhutdinov@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah

________________________________________
From: Stefan Hajnoczi [stefanha@redhat.com]
Sent: Wednesday, January 22, 2020 11:12 AM
To: Michael S. Tsirkin
Cc: Damir Shaikhutdinov; virtio-comment@lists.oasis-open.org
Subject: Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed.

On Wed, Jan 22, 2020 at 12:53:37AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 21, 2020 at 04:08:18PM +0000, Stefan Hajnoczi wrote:
> > On Mon, Jan 20, 2020 at 11:21:36AM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 20, 2020 at 11:45:05AM +0000, Damir Shaikhutdinov wrote:
> > > > Hello!
> > > >
> > > > While reading section 5.2 of the spec, I found that VIRTIO_BLK_F_RO feature could use
> > > > some additional clarification regarding handling requests when it was offered.
> > > >
> > > > This RO feature is described as "Device is read only" (Section 5.2.3). There are some explicit requirements for this feature, but they only describe a "write request".
> > > >
> > > > 5.2.5 p3 says "If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail."
> > > >
> > > > 5.2.6 says "The type of the request is either a read (VIRTIO_BLK_T_IN), a write (VIRTIO_BLK_T_OUT) ...", so "write request" mentioned in 5.2.5 p3 is VIRTIO_BLK_T_OUT.
> > > >
> > > > 5.2.6.2 says "A device MUST set the status byte to VIRTIO_BLK_S_IOERR for a write request if the VIRTIO_BLK_F_RO
> > > > feature if offered, and MUST NOT write any data."
> > > >
> > > > What is missing here is a requirement for features and other types of requests in case of VIRTIO_BLK_F_RO:
> > > >
> > > > * config.writeback field (guarded by VIRTIO_BLK_F_CONFIG_WCE feature)
> > > > * VIRTIO_BLK_T_ FLUSH (guarded by VIRTIO_BLK_F_FLUSH feature)
> > > > * VIRTIO_BLK_T_DISCARD (guarded by VIRTIO_BLK_F_DISCARD feature)
> > > > * VIRTIO_BLK_T_WRITE_ZEROES (guarded by VIRTIO_BLK_F_WRITE_ZEROES feature)
> > > >
> > > > Configuration field, requests and features described above make no sense in presence of VIRTIO_BLK_F_RO.
> > > >
> > > > This can be clarified in several ways, for example:
> > > >
> > > > 1. Device should not offer CONFIG_WCE, FLUSH, DISCARD and WRITE_ZEROES features if it offers RO feature (partially contradicts 5.2.5.2 "Device SHOULD always offer VIRTIO_BLK_F_FLUSH")
> > > > 2. Device must set the status byte to IOERR for FLUSH, DISCARD and WRITE_ZEROES requests if it offers RO feature.
> > > >
> > > >
> > > > What do you think about that?
> > >
> > > I guess flush can even be allowed, it's harmless if nothing is written,
> > > right?
> >
> > I agree.  There seems to be no benefit in failing it and there's a small
> > chance that some drivers could get upset if it fails (typically when a
> > common code path submits a flush request and expects it to succeed).
> >
> > > I agree DISCARD and WRITE_ZEROES must fail. And set VIRTIO_BLK_S_IOERR
> > > I guess?
> >
> > Yes.
> >
> > > It's too late to disallow configurations such as a combination of VIRTIO_BLK_F_CONFIG_WCE
> > > and VIRTIO_BLK_F_RO, devices out there might be setting this combination.
> >
> > Yes.
> >
> > Stefan
>
> Thanks! Stefan do you have the time to work on a spec patch to fix this?
> Damir do you?

Damir, you can find instructions for contributing to the virtio
specification here:

https://github.com/oasis-tcs/virtio-spec/

If you don't have time to write a patch please let me know.

Stefan

Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>


[tech_days_munchen]

OpenSynergy TechDay München

am 11. Februar 2020, ab 12:00Uhr, im Studio Balan, Moosacherstr. 86.

Anmeldung bitte hier<mailto:sabine.mutumba@opensynergy.com>

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/