A descripancy on SBP2 spec 1998

Eric Anderson ewa at apple.com
Tue Feb 28 17:47:10 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Eric Anderson <ewa at apple.com>
*
Hi Sudeep,
You asked:
> Looking at figure 8 in section 4.4, your explaination is rational,
> but,
> in actual normalised page tables, there are two entries (lets
> concentrate on first segment only), segment base address and offset.
> If offset points to the segment start address, then where does
> segnment
> base adress point to ?
No, offset does *not* (by itself) point to the segment start address,
because offset is only 12 bits long, so offset is too small to be an
address pointer.
Segment_base_hi and segment_base_lo together provide 36 bits.  This
is also too small to be an address (because the address requires 48
bits).
So to find the data address, you must use all the values:
segment_base_hi, segment_base_lo, and segment_offset.  Together,
these are 48 bits and they provide a complete address.
If we use the example from Figure 8, the normalized page table is:
(entry 0): len=0x0564, followed by 0x000000ceaa9c
(entry 1): len=0x1000, followed by 0x000000cec000
etc.
So, because page_size is 4, the page table entry format is exactly as
shown in Figure 24.  So we can read the above data as follows, by
using Figure 24:
(entry 0): len=0x0564, base_hi=0x0000, base_lo=0x00cea, offset=0xa9c
(entry 1): len=0x1000, base_hi=0x0000, base_lo=0x00cec, offset=0x000
etc.
But you wrote:
> Then as per the figure 8, does the segment base address point to
> system
> page boundary of 0xCEA000, with offset pointing to segment start of
> 0xCEAA9C.
Now I hope you can see the answer.  offset is only 12 bits: 0xa9c
(not 0xCEAA9C); so offset (by itself) is not enough information to
find the data.	Also, segment_base (36 bits) is really 0x000000cea
(not 0xCEA000).  When you concatenate segment base hi, base lo, and
offset, then you get 0x000000ceaa9c, which is the 48-bit address to
the data.
If you are still confused, please print a copy of Figure 24 on paper,
then try to write the value 0x0564000000ceaa9c into Figure 24 by
lining up the bits carefully - there are 64 bits in Figure 24, so the
64-bit number 0x0564000000ceaa9c should fit perfectly.	Then I think
you will see how segment_base_hi, segment_base_lo, and segment_offset
all work together to provide the data address.
So the SBP-2 spec is correct. (and also somewhat confusing)
OK?
Eric
On Feb 26, 2006, at 8:37 PM, sudeep.biswas at wipro.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <sudeep.biswas at wipro.com>
> *
>
> Hi Eric,
>
> Thanks
> Looking at figure 8 in section 4.4, your explaination is rational,
> but,
> in actual normalised page tables, there are two entries (lets
> concentrate on first segment only), segment base address and offset.
> If offset points to the segment start address, then where does
> segnment
> base adress point to ?
> Then as per the figure 8, does the segment base address point to
> system
> page boundary of 0xCEA000, with offset pointing to segment start of
> 0xCEAA9C.
> But explaination of segment_base_Hi/Lo under figure 24 in section
> 5.2.2
> is confusing in this context.
> I am quoting it for you as below.
>
> " The segment_base_hi and segment_base_lo fields together shall
> specify
> the base address of the
> segment within the node's 48-bit system memory address range.
> The segment_offset field shall contain the starting address for data
> transfer within the segment."
>
> Please comment.
>
> Regards,
>
> Sudeep
>
> -----Original Message-----
> From: Eric Anderson [mailto:ewa at apple.com]
> Sent: Saturday, February 25, 2006 5:20 AM
> To: Sudeep Biswas (WT01 - Semiconductors IP Solutions)
> Cc: t10 at t10.org
> Subject: Re: A descripancy on SBP2 spec 1998
>
> Hello Sudeep,
>
> I think the text is confusing because the structure called "page
> table"
> would be more accurately called a "segment table".
>
> Pages are the regions in memory that start at fixed multiples starting
> from address zero, according to page_size.
>
> Segments are portions of memory described by the SBP-2 "page table".
> Mostly, the boundaries of the segments will match the boundaries of
> the
> system pages.
>
> So, if a segment in the "page table" has an offset, the segment starts
> at that offset, but the "system page" is not adjusted by the offset.
>
> For example, consider Figure 8 in section 4.4, and the text in section
> 4.4:
>
> The first segment starts at 0xCEAA9C and has length 0x0564.  This
> segment fits into (part of) the system page that starts at 0xCEA000
> and
> has length 0x1000.
>
> The second segment starts at 0xCEC000 and has length 0x1000.	This
> second segment exactly matches the system page at 0xCEC000.
>
> The fourth segment starts at 0xCEF000 and has length 0x03FC.	This
> segment fits into (part of) the system page at 0xCEF000 with length
> 0x1000.
>
> It is the system page boundaries at 0xCEA000, 0xCEB000, 0xCEC000,
> etc.,
> that must not be crossed when accessing data.
>
> So a legal access would be:
>
> 1. Read 0x0564 bytes at 0xCEAA9C
> 2. Read 0x1000 bytes at 0xCEC000
> 3. Read 0x1000 bytes at 0xCED000
> 4. Read 0x03FC bytes at 0xCEF000
>
> However, this access would be illegal:
>
> 5. Read 0x0564 bytes at 0xCEAA9C
> 6. Read 0x2000 bytes at 0xCEC000
> 7. Read 0x03FC bytes at 0xCEF000
>
> ... because read 6 would "cross" the (system) page boundary at
> 0xCED000.
> (By the way, read 6 would also be too large for 1394, where the
> largest
> asynchronous packet size is 0x1000 bytes).
>
> So, to answer your question, for normalized page tables, the system
> page
> boundaries (which must not be crossed) exist at fixed multiples
> starting
> from address zero.  The system page boundary does not depend on the
> segment base address in the ORB.
>
> Does that help?
>
> Eric
>
>
>
> On Feb 22, 2006, at 12:11 AM, sudeep.biswas at wipro.com wrote:
>
>>
>> Hello Eric,
>>
>> Thanks.
>>
>> Certainly this has resolved my understanding of contigous data
>> memory,
>
>> but am I right in saying that, this explaination does not exactly fit
>> on normalised page tables, because there the page boundary depends on
>> the segment base address specified  in the page elements.
>> Please comment.
>>
>> Thanks and regards,
>> Sudeep biswas
>> Project Engineer
>> Wipro Technologies
>> Pune, India
>> 411057
>>
>> -----Original Message-----
>> From: Eric Anderson [mailto:ewa at apple.com]
>> Sent: Wednesday, February 22, 2006 12:58 AM
>> To: Sudeep Biswas (WT01 - Semiconductors IP Solutions)
>> Cc: t10 at t10.org
>> Subject: Re: A descripancy on SBP2 spec 1998
>>
>> Hello Sudeep,
>>
>> Figure 7 is correct, but the example is confusing because some
>> information is missing.
>>
>> For the example described using Figure 7, the ORB specifies p=0 and
>> page_size=4.  p=0 (page_table_present=0) indicates that no page table
>> is used, so data_descriptor points directly to the first byte of the
>> data buffer.  However, page_size=4 indicates the system has 4096-byte
>> (0x1000) page boundaries.  (This value of 4 is not clearly
>> mentioned.)
>>
>> This combination of p=0 and page_size=4 places some restrictions on
>> how the SBP-2 target may access the data.
>>
>> In the example, the data length is 0x3088 and the data address is
>> 0x236174.  So, system page boundaries occur inside the buffer at
>> 0x237000, 0x238000, and 0x239000 as suggested in Figure 7.
>>
>> A valid operation by the printer would be to transfer data like this:
>>
>> 1. Read 0x0E8C bytes at 0x236174
>> 2. Read 0x1000 bytes at 0x237000
>> 3. Read 0x1000 bytes at 0x238000
>> 4. Read 0x01FC bytes at 0x239000
>>
>> For comparison, the following operation would be invalid:
>>
>> 5. Read 0x1000 bytes at 0x236174
>> 6. Read 0x1000 bytes at 0x237174
>> 7. Read 0x1000 bytes at 0x238174
>> 8. Read 0x0088 bytes at 0x239174
>>
>> The second example (5-8) is invalid, because read 5 will cross the
>> page boundary at 0x237000, and read 6 will cross the page boundary at
>> 0x238000, and read 7 will cross the page boundary at 0x239000.
>> Because p=0 and page_size=4, such reads are illegal.
>>
>> In other words, the page boundaries are located at multiples of
>> 0x1000
>
>> (in this example).  The location of the page boundaries does not
>> depend on where the buffer begins; instead, the page boundaries are
>> fixed in system memory based on the system page size.
>>
>> Does this answer your question?
>>
>> Eric Anderson
>> Apple Computer, Inc.
>> ewa at apple.com
>>
>>
>> On Feb 21, 2006, at 1:28 AM, sudeep.biswas at wipro.com wrote:
>>
>>>
>>> Hello ,
>>>
>>> This is regarding a confusion on SBP2 spec about contiguos data
>>> buffer.
>>> According to Page number 14 and 15, under 4.4 Data Buffers, and page
>>> number 62, under 9.2 Data Transfer of SBP2 specs Rev 2 May 19,1998,
>>> even when p =0 in an ORB, it can have page boudaries according to
>>> the
>
>>> page_size (if page_size is nonzero), and without page boudaries if
>>> page_size is zero, and in figure 7, the data descriptor points to a
>>> data buffer start location where the first page boundary does not
>>> appear on page_size, which shows an offset on first page.
>>> If there should be a offset which is described by the
>>> data_descriptor
>
>>> then what describes the base address for the same ?
>>> or is there a bug in the figure 7, so that the data_descriptot shows
>>> the base address/starting address and from the first page onwards,
>>> every page has full page_sige only.
>>>
>>> Please advice ASAP since we are in mid of designing the SBP2
>>> protocol
>
>>> for our customer and we are stuck in between.
>>>
>>> Thanks and regards,
>>>
>>> Sudeep Biswas
>>> Project Engineer
>>> Wipro Technologies
>>> Pune, India
>>> 411057
>>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list