Discussion:
Feedback for CSPRD03
Pawel Moll
2014-07-21 14:06:57 UTC
Permalink
Greetings,

I've finally managed to "convince" one of my colleagues to provide some
feedback. Thanks, Brian! (I'm just acting as an IPR proxy here...)

Here it goes:


* 2.3.1 "nor reads from multiple fields"

Should be "nor *are* reads...", possibly "from multiple adjacent
fields"?


* 2.3.4 "This effects the block capacity and network mac fields"

Should be "This *affects* the block capacity and network MAC fields"


* 2.4 "When the device has finished a buffer"

Would this be clearer as "When the device has finished
*using/accessing/processing/something* a buffer"?


* 2.4.5.3.1 "The driver MUST NOT set the VRING_DESC_F_INDIRECT flag
unless the VIRTIO_RING_F_INDIRECT_DESC feature was negotiated."

What happens if we set the flag? Should we explicitly say the device
ignores it? Is there any way of signalling an error?


* 2.4.5.3.1 "The driver MUST NOT set the VIRTQ_DESC_F_INDIRECT flag
within an indirect descriptor (ie. only one table per descriptor)."

OK, good, but again what does the failure mode look like? Should the
device ignore it?


* 3.1.1 "If any of these steps go irrecoverably wrong, the driver SHOULD
set the FAILED status bit to indicate that it has given up on the device
(it can reset the device later to restart if desired). The driver MUST
not continue initialization in that case."

In terms of impl, does this mean if FAILED is set, the device must
respond to nothing but reset?


* 3.1.1 "The driver MUST not accept"

Should be "The driver MUST NOT accept"


* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."

This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.


* 4.2 "Therefore most of operations like..."

Should be "Therefore most operations including"


* 4.2.1 "MMIO provides no generic device discovery"

Should be "MMIO provides no generic device discovery mechanism"


* 4.2.2 "MMIO virtio devices provides"

Should be "MMIO virtio devices provide" or "An MMIO virtio device
provides"


* 4.2.2 DeviceFeatures, DriverFeatures: "First bit"

Should probably be "the least signficiant bit".


* 4.2.2 QueueNum "therefore size of the Descriptor Table and both
Available and Used rings"

This is a bit confusing and a bit ambiguous. I think it would be clearer
as "i.e. the size of the descriptor table, the number of entries in the
availabe ring, and the number of entries in the used ring." (otherwise
it's not clear if you mean size(DT) == size(available)+size(used), or


* 4.2.2 QueueReady: "Ready to be used"

Slightly confusing here: could mean 'CPU has updated the available
ring/DT', when it really means 'the DT/available ring have first been
initialised to sensible values'. Might be better to copy the PCI
description which says 'the device may execute requests from this
virtual queue'.


* 4.2.2 ConfigGeneration:

I was a bit lost as to what counts as a configuration change. I think
the ref to section 2.3 doesn't help. Sec 4.2.2.1 is a bit better: "The
device MUST change ConfigGeneration if there is any risk of a device
seeing an inconsistent configuration state, but it MAY only change the
value after a configuration read operation.", but I think that the PCI
description (and the note following) is a bit clearer: "The device MUST
present a changed config_generation after the driver has read a
device-specific configuration value which has changed since any part of
the device-specific configuration was last read. (Note, counter can wrap
so do this...)


* 4.2.2 InterruptAck: "Writing to this register notifies the device that
the interrupt has been handled"

Does this mean if InterruptStatus=3 and I write 1, I'm acking the ring
update but not the configuration change? What happens if I try to ack
something that hasn't happened, eg write 3 when InterruptStatus==0?


* 4.2.2 Along with saying the registers are LE, should we say that all
register accesses must be aligned, 32-bit accesses, and anything else is
undefined behaviour?


* 4.2.2.2 "When QueueReady is not zero, the drive..."

Period missing at end of sentence.


* 5.1.6.5.7.2 "a offload"

Should be "an offload"


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-***@lists.oasis-open.org

Unsubscribe: virtio-comment-***@lists.oasis-open.org

List help: virtio-comment-***@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/
Pawel Moll
2014-07-21 14:32:53 UTC
Permalink
Post by Pawel Moll
* 2.4.5.3.1 "The driver MUST NOT set the VRING_DESC_F_INDIRECT flag
unless the VIRTIO_RING_F_INDIRECT_DESC feature was negotiated."
What happens if we set the flag? Should we explicitly say the device
ignores it? Is there any way of signalling an error?
* 2.4.5.3.1 "The driver MUST NOT set the VIRTQ_DESC_F_INDIRECT flag
within an indirect descriptor (ie. only one table per descriptor)."
OK, good, but again what does the failure mode look like? Should the
device ignore it?
* 3.1.1 "If any of these steps go irrecoverably wrong, the driver SHOULD
set the FAILED status bit to indicate that it has given up on the device
(it can reset the device later to restart if desired). The driver MUST
not continue initialization in that case."
In terms of impl, does this mean if FAILED is set, the device must
respond to nothing but reset?
I disagree woth my esteemed colleague on these three... To my mind, what
is not allowed is forbidden and out of scope.
Post by Pawel Moll
* 4.2.1 "MMIO provides no generic device discovery"
Should be "MMIO provides no generic device discovery mechanism"
Fair enough, will fix.
Post by Pawel Moll
* 4.2.2 "MMIO virtio devices provides"
Should be "MMIO virtio devices provide" or "An MMIO virtio device
provides"
Agreed.
Post by Pawel Moll
* 4.2.2 DeviceFeatures, DriverFeatures: "First bit"
Should probably be "the least signficiant bit".
Good idea.
Post by Pawel Moll
* 4.2.2 QueueNum "therefore size of the Descriptor Table and both
Available and Used rings"
This is a bit confusing and a bit ambiguous. I think it would be clearer
as "i.e. the size of the descriptor table, the number of entries in the
availabe ring, and the number of entries in the used ring." (otherwise
it's not clear if you mean size(DT) == size(available)+size(used), or
Ok, let me remove the "size" bit then:

"Queue size is the number of elements in the queue, therefore in each of
the Descriptor Table, and the Available Ring and the Used Ring."
Post by Pawel Moll
* 4.2.2 QueueReady: "Ready to be used"
Slightly confusing here: could mean 'CPU has updated the available
ring/DT', when it really means 'the DT/available ring have first been
initialised to sensible values'. Might be better to copy the PCI
description which says 'the device may execute requests from this
virtual queue'.
"Writing one (0x1) to this register notifies the device that it may
execute requests from this virtual queue."
Post by Pawel Moll
I was a bit lost as to what counts as a configuration change. I think
the ref to section 2.3 doesn't help. Sec 4.2.2.1 is a bit better: "The
device MUST change ConfigGeneration if there is any risk of a device
seeing an inconsistent configuration state, but it MAY only change the
value after a configuration read operation.", but I think that the PCI
description (and the note following) is a bit clearer: "The device MUST
present a changed config_generation after the driver has read a
device-specific configuration value which has changed since any part of
the device-specific configuration was last read. (Note, counter can wrap
so do this...)
I'll add reference to 4.2.2.1 and fix the sentence there, so it is
actually correct (currently it's saying "if there is any risk of a
device seeing an inconsistent configuration state", should be "driver
seeing").
Post by Pawel Moll
* 4.2.2 InterruptAck: "Writing to this register notifies the device that
the interrupt has been handled"
Does this mean if InterruptStatus=3 and I write 1, I'm acking the ring
update but not the configuration change?
Yes, I'll expand the description to make it clearer.
Post by Pawel Moll
What happens if I try to ack
something that hasn't happened, eg write 3 when InterruptStatus==0?
Illegal operation, out of scope, but I'll add a MUST NOT to make it
explicit.
Post by Pawel Moll
* 4.2.2 Along with saying the registers are LE, should we say that all
register accesses must be aligned, 32-bit accesses, and anything else is
undefined behaviour?
Yes! The requirement for aligned access was there originally, must have
got lost in translation. Will fix.
Post by Pawel Moll
* 4.2.2.2 "When QueueReady is not zero, the drive..."
Period missing at end of sentence.
Sure thing.

Will send a patch fixing all above soon. Looks "non material" to me :-)

Paweł


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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-22 19:20:31 UTC
Permalink
Post by Pawel Moll
Greetings,
I've finally managed to "convince" one of my colleagues to provide some
feedback. Thanks, Brian! (I'm just acting as an IPR proxy here...)
* 2.3.1 "nor reads from multiple fields"
Should be "nor *are* reads...", possibly "from multiple adjacent
fields"?
* 2.3.4 "This effects the block capacity and network mac fields"
Should be "This *affects* the block capacity and network MAC fields"
* 2.4 "When the device has finished a buffer"
Would this be clearer as "When the device has finished
*using/accessing/processing/something* a buffer"?
* 2.4.5.3.1 "The driver MUST NOT set the VRING_DESC_F_INDIRECT flag
unless the VIRTIO_RING_F_INDIRECT_DESC feature was negotiated."
What happens if we set the flag?
Historically devices followed the descriptor bit ignoring the feature.
Post by Pawel Moll
Should we explicitly say the device
ignores it?
I don't see a lot of value.
Post by Pawel Moll
Is there any way of signalling an error?
No as we don't have good ways to signal driver bugs at the moment.
I doubt we can do this for 1.0, post 1.0 it's one area
which could be improved. When we have that, we can use it.
Post by Pawel Moll
* 2.4.5.3.1 "The driver MUST NOT set the VIRTQ_DESC_F_INDIRECT flag
within an indirect descriptor (ie. only one table per descriptor)."
OK, good, but again what does the failure mode look like? Should the
device ignore it?
Historically devices behaved in different broken ways.
Post by Pawel Moll
* 3.1.1 "If any of these steps go irrecoverably wrong, the driver SHOULD
set the FAILED status bit to indicate that it has given up on the device
(it can reset the device later to restart if desired). The driver MUST
not continue initialization in that case."
In terms of impl, does this mean if FAILED is set, the device must
respond to nothing but reset?
I don't think it's worth enforcing by the device.
Post by Pawel Moll
* 3.1.1 "The driver MUST not accept"
Should be "The driver MUST NOT accept"
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
* 4.2.1 "MMIO provides no generic device discovery"
Should be "MMIO provides no generic device discovery mechanism"
* 4.2.2 "MMIO virtio devices provides"
Should be "MMIO virtio devices provide" or "An MMIO virtio device
provides"
* 4.2.2 DeviceFeatures, DriverFeatures: "First bit"
Should probably be "the least signficiant bit".
* 4.2.2 QueueNum "therefore size of the Descriptor Table and both
Available and Used rings"
This is a bit confusing and a bit ambiguous. I think it would be clearer
as "i.e. the size of the descriptor table, the number of entries in the
availabe ring, and the number of entries in the used ring." (otherwise
it's not clear if you mean size(DT) == size(available)+size(used), or
* 4.2.2 QueueReady: "Ready to be used"
Slightly confusing here: could mean 'CPU has updated the available
ring/DT', when it really means 'the DT/available ring have first been
initialised to sensible values'. Might be better to copy the PCI
description which says 'the device may execute requests from this
virtual queue'.
I was a bit lost as to what counts as a configuration change. I think
the ref to section 2.3 doesn't help. Sec 4.2.2.1 is a bit better: "The
device MUST change ConfigGeneration if there is any risk of a device
seeing an inconsistent configuration state, but it MAY only change the
value after a configuration read operation.", but I think that the PCI
description (and the note following) is a bit clearer: "The device MUST
present a changed config_generation after the driver has read a
device-specific configuration value which has changed since any part of
the device-specific configuration was last read. (Note, counter can wrap
so do this...)
* 4.2.2 InterruptAck: "Writing to this register notifies the device that
the interrupt has been handled"
Does this mean if InterruptStatus=3 and I write 1, I'm acking the ring
update but not the configuration change? What happens if I try to ack
something that hasn't happened, eg write 3 when InterruptStatus==0?
* 4.2.2 Along with saying the registers are LE, should we say that all
register accesses must be aligned, 32-bit accesses, and anything else is
undefined behaviour?
* 4.2.2.2 "When QueueReady is not zero, the drive..."
Period missing at end of sentence.
* 5.1.6.5.7.2 "a offload"
Should be "an offload"
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.
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-***@lists.oasis-open.org

Unsubscribe: virtio-comment-***@lists.oasis-open.org

List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-22 19:25:16 UTC
Permalink
Post by Pawel Moll
Greetings,
I've finally managed to "convince" one of my colleagues to provide some
feedback. Thanks, Brian! (I'm just acting as an IPR proxy here...)
I saw that you already sent patches for most things.
Thanks!
Post by Pawel Moll
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate
unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
and
Post by Pawel Moll
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
Correct?
Could you please create issues for stuff that is left, so we can fix?


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-***@lists.oasis-open.org

Unsubscribe: virtio-comment-***@lists.oasis-open.org

List help: virtio-comment-***@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/
Pawel Moll
2014-07-23 11:50:09 UTC
Permalink
Post by Pawel Moll
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate
unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
https://issues.oasis-open.org/browse/VIRTIO-112
Post by Pawel Moll
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
The second thing should be actually included in the MMIO fix, will add.

Paweł



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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-30 11:46:49 UTC
Permalink
Post by Pawel Moll
Post by Pawel Moll
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
https://issues.oasis-open.org/browse/VIRTIO-112
Looks like environment is not set to include the reporter.

If Brian doesn't want to keep his name secret,
please set environment to reporter's name and optionally
email address.
If it's a secret, please set yours there instead.
Post by Pawel Moll
Post by Pawel Moll
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
The second thing should be actually included in the MMIO fix, will add.
Paweł
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-30 12:20:37 UTC
Permalink
Post by Michael S. Tsirkin
Post by Pawel Moll
Post by Pawel Moll
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
https://issues.oasis-open.org/browse/VIRTIO-112
Looks like environment is not set to include the reporter.
If Brian doesn't want to keep his name secret,
please set environment to reporter's name and optionally
email address.
If it's a secret, please set yours there instead.
Ugh I see it now. Donnu why I missed it, sorry.

Minor issue: <> got converted to &lt; &gt;.
This seems to be a bug when creating issues.
I fixed it up for environment for this bug, could affect
other bugs.

Same affects descriptions as well.

At the moment because of this bug it seems best to create empty issues,
then press edit to fill in the data.
Edit does not seem to suffer from this problem.

Also pls do not add "Reported-by:" in environment,
makes it harder to extract addresses automatically.


Thanks!
Post by Michael S. Tsirkin
Post by Pawel Moll
Post by Pawel Moll
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
The second thing should be actually included in the MMIO fix, will add.
Paweł
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-30 12:25:11 UTC
Permalink
Post by Michael S. Tsirkin
Post by Michael S. Tsirkin
Post by Pawel Moll
Post by Pawel Moll
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, and
thus did not have a graceful way for the device to indicate unsupported
feature combinations. It also did not provide a clear mechanism to
end feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device."
This has mixed tenses ("do not"/"did not"/"which meant"). Probably
should all be present tense, since all the statements are still true of
legacy devices now as well as in the past.
https://issues.oasis-open.org/browse/VIRTIO-112
Looks like environment is not set to include the reporter.
If Brian doesn't want to keep his name secret,
please set environment to reporter's name and optionally
email address.
If it's a secret, please set yours there instead.
Ugh I see it now. Donnu why I missed it, sorry.
This seems to be a bug when creating issues.
I fixed it up for environment for this bug, could affect
other bugs.
Same affects descriptions as well.
At the moment because of this bug it seems best to create empty issues,
then press edit to fill in the data.
Edit does not seem to suffer from this problem.
Also pls do not add "Reported-by:" in environment,
makes it harder to extract addresses automatically.
Thanks!
Also, affects versions should be set at least to csprd03.
After fixing, pls set it to csprd04 (if we don't go for prd04
I will rename the version, this is not a problem).
Post by Michael S. Tsirkin
Post by Michael S. Tsirkin
Post by Pawel Moll
Post by Pawel Moll
* 4.2 "Therefore most of operations like..."
Should be "Therefore most operations including"
The second thing should be actually included in the MMIO fix, will add.
Paweł
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Pawel Moll
2014-07-30 13:23:57 UTC
Permalink
Post by Michael S. Tsirkin
Post by Michael S. Tsirkin
If Brian doesn't want to keep his name secret,
please set environment to reporter's name and optionally
email address.
If it's a secret, please set yours there instead.
Ugh I see it now. Donnu why I missed it, sorry.
Because I've just set it up?
Post by Michael S. Tsirkin
This seems to be a bug when creating issues.
I fixed it up for environment for this bug, could affect
other bugs.
Same affects descriptions as well.
At the moment because of this bug it seems best to create empty issues,
then press edit to fill in the data.
Edit does not seem to suffer from this problem.
On the contrary. It was fine when I submitted it, it was your edit that
made it &quoted; - see activities log:

Michael Tsirkin made changes - Today 12:09 PM

Environment
Reported-by: Brian Foley <***@arm.com>
Reported-by: Brian Foley &lt;***@arm.com&gt;

Description
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, [...]
* 3.1.2 &quot;Legacy devices do not support the FEATURES_OK status bit,
[...]
Post by Michael S. Tsirkin
Also pls do not add "Reported-by:" in environment,
makes it harder to extract addresses automatically.
Just copied the style from VIRTIO-106. Anyway, removed the reported-by
bits from all 3 bugs. Also modified affects/fix versions.

Paweł


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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/
Michael S. Tsirkin
2014-07-30 14:36:44 UTC
Permalink
Post by Pawel Moll
Post by Michael S. Tsirkin
Post by Michael S. Tsirkin
If Brian doesn't want to keep his name secret,
please set environment to reporter's name and optionally
email address.
If it's a secret, please set yours there instead.
Ugh I see it now. Donnu why I missed it, sorry.
Because I've just set it up?
Post by Michael S. Tsirkin
This seems to be a bug when creating issues.
I fixed it up for environment for this bug, could affect
other bugs.
Same affects descriptions as well.
At the moment because of this bug it seems best to create empty issues,
then press edit to fill in the data.
Edit does not seem to suffer from this problem.
On the contrary. It was fine when I submitted it, it was your edit that
Michael Tsirkin made changes - Today 12:09 PM
Environment
Description
* 3.1.2 "Legacy devices do not support the FEATURES_OK status bit, [...]
* 3.1.2 &quot;Legacy devices do not support the FEATURES_OK status bit,
[...]
Aha! thanks for this - this was a bug in the script
I use to update proposals as mail is sent:
it was encoding all fields twice.
Fixed now so should not happen anymore.
Post by Pawel Moll
Post by Michael S. Tsirkin
Also pls do not add "Reported-by:" in environment,
makes it harder to extract addresses automatically.
Just copied the style from VIRTIO-106. Anyway, removed the reported-by
bits from all 3 bugs. Also modified affects/fix versions.
Paweł
Thanks!

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-***@lists.oasis-open.org
Unsubscribe: virtio-comment-***@lists.oasis-open.org
List help: virtio-comment-***@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/

Loading...