[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [RFC PATCH] virtio-rpmb: fix spec land mine in max_[wr|rd]_cnt
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]