From: "Alex Bennée" <alex.bennee@linaro.org>
To: Harald Mommer <harald.mommer@opensynergy.com>
Cc: virtio-comment@lists.oasis-open.org,
Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
Harald Mommer <hmo@opensynergy.com>,
Will Deacon <will@kernel.org>
Subject: Re: [virtio-comment] [RFC PATCH] virtio-rpmb: fix spec land mine in max_[wr|rd]_cnt
Date: Mon, 26 Jun 2023 21:03:58 +0100 [thread overview]
Message-ID: <874jmu2dir.fsf@linaro.org> (raw)
In-Reply-To: <8d5fc5be-1db8-65c1-c8ab-9fbd10808a59@opensynergy.com>
Harald Mommer <harald.mommer@opensynergy.com> writes:
> Hello,
>
> this damned "unlimited" makes me crazy. Nothing in a computer is unlimited.
>
> How easy could life have been if the virtio spec had used 16 bit
> values for max_wr_cnt and max_rd_cnt in the config space but it is as
> it is and this cannot be changed any more.
>
> On 19.06.23 14:01, Alex Bennée wrote:
>> Even if 0 meant no limit we are still limited by the field size of the
>> request. That said for a maximum sized partition (* 80 128 1024) you
>> could only actually request 40960 blocks before running out of device.
>> Perhaps it would be better to mark 0 as invalid?
>
> Where comes this 80 from? I saw a 0x80 in the virtio specification,
> which would be 128 and not 80 decimal.
Ahh yes of course so a potential maximum of 16777216, but as you say...
>> Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>> Cc: Harald Mommer <hmo@opensynergy.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>> device-types/rpmb/description.tex | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/device-types/rpmb/description.tex b/device-types/rpmb/description.tex
>> index 1dae3fd..2ce8a5b 100644
>> --- a/device-types/rpmb/description.tex
>> +++ b/device-types/rpmb/description.tex
>> @@ -37,7 +37,7 @@ \subsection{Device configuration layout}\label{sec:Device Types / RPMB Device /
>> The values MUST range between 0x00 and 0x80 inclusive.
>> \item[\field{max_wr_cnt and max_rd_cnt}] are the maximum numbers of RPMB
>> block count (256B) that can be performed to device in one request. 0 implies
>> - no limitation.
>> + no limitation other than the maximum value you can store in \field{block_count} (65535).
>> \end{description}
>
> Yes, 65535 is what fits in the 2 byte block count of various
> underlying storage technology specs. So 65535 is an upper limit.
> Smallest upper limit which makes sense? I guess no as there is
> underlying storage technology.
>
> JESD85-B51 for eMMC:
>
> Looking at 6.6.22.4.3 Authenticated Data Write I see that at least for
> write 2 or 3 sizes may be supported:
>
> 1 block, 2 blocks and optionally 32 blocks but nothing in between of 2
> and 32.
>
> This is strange. If I understand this correctly (Maybe but I'm not
> sure) the limits of the underlying storage technology cannot be always
> represented cleanly by the virtio config space definitions due to the
> missing 3..31 value range.
I guess this depends on the backing store. Currently all the backends
I'm aware of emulate the RPMB storage but surely sometimes the
virtio-rpmb interface will be backed by a "real" RPMB partition.
> JESD220C-2.2 for UFS is more friendly:
>
> 14.1.4.4 Geometry descriptor
>
> bRPMB_ReadWriteSize is an 8 bit value, 0 seems not to be foreseen. 255
> is the theoretical maximum and we don't have to cope with 0 means
> "unlimited".
>
> And then I found something in an NVMe spec (NVM Express® Base
> Specification, revision 2.0b)
>
> Figure 275 says that in bytes 315:312 some bits 31:24 (8 bits)
>
> "Access Size: If the Number of RPMB Units field is non-zero, then this
> field indicates the maximum number of 512B units of data that may be
> read or written per RPMB access by Security Send or Security Receive
> commands for the controller. This is a 0’s based value. A value of 0h
> indicates support for one unit of 512B of data."
>
> So if I understand this correctly NVMe has the biggest limit with 255 + 1.
>
> Considering current storage technology it could be that in practice
> for now the best implementation choice when interpreting "unlimited"
> may be to interpret this as "256".
>
> Replacing the word "unlimited" by "65535" may not be what should be
> done here.
Seems reasonable.
>
>> \devicenormative{\subsection}{Device Initialization}{Device
>> Types / RPMB Device / Device Initialization}
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
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/
prev parent reply other threads:[~2023-06-26 20:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 12:01 [virtio-comment] [RFC PATCH] virtio-rpmb: fix spec land mine in max_[wr|rd]_cnt Alex Bennée
2023-06-21 9:30 ` Cornelia Huck
2023-06-22 13:16 ` Alex Bennée
2023-06-26 19:05 ` Harald Mommer
2023-06-26 20:03 ` Alex Bennée [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jmu2dir.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=harald.mommer@opensynergy.com \
--cc=hmo@opensynergy.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=virtio-comment@lists.oasis-open.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).