* [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. @ 2020-01-20 11:45 Damir Shaikhutdinov 2020-01-20 16:21 ` Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Damir Shaikhutdinov @ 2020-01-20 11:45 UTC (permalink / raw) To: virtio-comment@lists.oasis-open.org 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. 2020-01-20 11:45 [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed Damir Shaikhutdinov @ 2020-01-20 16:21 ` Michael S. Tsirkin 2020-01-21 16:08 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2020-01-20 16:21 UTC (permalink / raw) To: Damir Shaikhutdinov; +Cc: virtio-comment@lists.oasis-open.org 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. 2020-01-20 16:21 ` Michael S. Tsirkin @ 2020-01-21 16:08 ` Stefan Hajnoczi 2020-01-22 5:53 ` Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2020-01-21 16:08 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Damir Shaikhutdinov, virtio-comment@lists.oasis-open.org [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. 2020-01-21 16:08 ` Stefan Hajnoczi @ 2020-01-22 5:53 ` Michael S. Tsirkin 2020-01-22 10:12 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2020-01-22 5:53 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Damir Shaikhutdinov, virtio-comment@lists.oasis-open.org 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. 2020-01-22 5:53 ` Michael S. Tsirkin @ 2020-01-22 10:12 ` Stefan Hajnoczi 2020-01-23 11:08 ` Damir Shaikhutdinov 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2020-01-22 10:12 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Damir Shaikhutdinov, virtio-comment@lists.oasis-open.org [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed. 2020-01-22 10:12 ` Stefan Hajnoczi @ 2020-01-23 11:08 ` Damir Shaikhutdinov 0 siblings, 0 replies; 6+ messages in thread From: Damir Shaikhutdinov @ 2020-01-23 11:08 UTC (permalink / raw) To: Stefan Hajnoczi, Michael S. Tsirkin; +Cc: virtio-comment@lists.oasis-open.org 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-23 11:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-20 11:45 [virtio-comment] Block Device VIRTIO_BLK_F_RO clarification needed Damir Shaikhutdinov 2020-01-20 16:21 ` Michael S. Tsirkin 2020-01-21 16:08 ` Stefan Hajnoczi 2020-01-22 5:53 ` Michael S. Tsirkin 2020-01-22 10:12 ` Stefan Hajnoczi 2020-01-23 11:08 ` Damir Shaikhutdinov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.