[Qemu OpenChannelSSD] Address Issues

注意:这篇里讲解的代码都是来自liblightnvm.git(lightnvm的用户态库,注意是最新的库,而不是先前那个由Matias Bjørling自己写的旧liblightnvm库)
Some Kinds of Address


[Qemu OpenChannelSSD] Address Issues_第1张图片
address (1).png

1.PPA(位域操作符定义的struct)[generic address]

struct nvm_addr {
    union {
        /**
         * Address packing and geometric accessors
         */
        struct {
            uint64_t blk    : NVM_BLK_BITS; ///< Block address
            uint64_t pg : NVM_PG_BITS;  ///< Page address
            uint64_t sec    : NVM_SEC_BITS; ///< Sector address
            uint64_t pl : NVM_PL_BITS;  ///< Plane address
            uint64_t lun    : NVM_LUN_BITS; ///< LUN address
            uint64_t ch : NVM_CH_BITS;  ///< Channel address
            uint64_t rsvd   : 1;        ///< Reserved
        } g;

        struct {
            uint64_t line       : 63;   ///< Address line
            uint64_t is_cached  : 1;    ///< Cache hint?
        } c;

        uint64_t ppa;               ///< Address as ppa
    };
};

PPA is NOT an address accepted by ssd controller, but an address for each part through a machine-can-tell address.(or I call it a human-readable-each-part-address-----generic address)

Let me explain by a simple example below:

a 16b machine-can-tell address  1101 1011 0000 0011
                                ---- ---- ---- ----
break apart                     P1   P2   P3   P4
struct example_addr{             |    |    |    |
    union{                     |      |    |    |
        struct {                 |    |    |    |  (in decimal)
            uint16_t p1 : 16;----|    |    |    |  13 
            uint16_t p2 : 16;-----------|    |    |  11
            uint16_t p3 : 16;----------------|    |  0
            uint16_t p4 : 16;---------------------|  3
        } g;
        //other field
        uint16_t ppa;
    };
};

2.同时,又有一个机器格式的地址 (device-address,which follows the fmt format)

struct nvm_dev {
    char name[NVM_DEV_NAME_LEN];    ///< Device name e.g. "nvme0n1"
    char path[NVM_DEV_PATH_LEN];    ///< Device path e.g. "/dev/nvme0n1"
    struct nvm_addr_fmt fmt;    ///< Device address format
    struct nvm_addr_fmt_mask mask;  ///< Device address format mask
    struct nvm_geo geo;     ///< Device geometry
    uint64_t ssw;           ///< Bit-width for LBA fmt conversion
    int pmode;          ///< Default plane-mode I/O
    int fd;             ///< Device fd / IOCTL handle
    int erase_naddrs_max;       ///< Maximum # of address for erase
    int read_naddrs_max;        ///< Maximum # of address for read
    int write_naddrs_max;       ///< Maximum # of address for write
    int bbts_cached;        ///< Whether to cache bbts
    size_t nbbts;           ///< Number of entries in cache
    struct nvm_bbt **bbts;      ///< Cache of bad-block-tables
};
  • 为什么会有一个ppa,又有一个fmt和mask?
  • 个人推测:
    ppa这种地址有一定的间隙,比如最大可以表示一个uint64_t的地址空间,但实际如flash本身size没这么大,有某些域会永远是零,特定的OCSSD,其地址格式(dev->fmt) will be different.
    My Fucking Input Software broke down:(... So I'm going to talk in Eng.
  • so convertion between a ppa and a device-format addr.:
generic --> dev-format
inline uint64_t nvm_addr_gen2dev(struct nvm_dev *dev, struct nvm_addr addr)
{
    uint64_t d_addr = 0;

    d_addr |= ((uint64_t)addr.g.ch) << dev->fmt.n.ch_ofz;
    d_addr |= ((uint64_t)addr.g.lun) << dev->fmt.n.lun_ofz;
    d_addr |= ((uint64_t)addr.g.pl) << dev->fmt.n.pl_ofz;
    d_addr |= ((uint64_t)addr.g.blk) << dev->fmt.n.blk_ofz;
    d_addr |= ((uint64_t)addr.g.pg) << dev->fmt.n.pg_ofz;
    d_addr |= ((uint64_t)addr.g.sec) << dev->fmt.n.sec_ofz;
    
    return d_addr;
}
generic <-- dev-format
inline struct nvm_addr nvm_addr_dev2gen(struct nvm_dev *dev, uint64_t addr)
{
    struct nvm_addr gen;

    gen.ppa = 0;
    gen.g.ch = (addr & dev->mask.n.ch) >> dev->fmt.n.ch_ofz;
    gen.g.lun |= (addr & dev->mask.n.lun) >> dev->fmt.n.lun_ofz;
    gen.g.pl|= (addr & dev->mask.n.pl) >> dev->fmt.n.pl_ofz;
    gen.g.blk |= (addr & dev->mask.n.blk) >> dev->fmt.n.blk_ofz;
    gen.g.pg |= (addr & dev->mask.n.pg) >> dev->fmt.n.pg_ofz;
    gen.g.sec |= (addr & dev->mask.n.sec) >> dev->fmt.n.sec_ofz;

    return gen;
}

3.另外就是lba和offset了,这两个比较好理解吧.
offset-format address: 偏移量是以字节(byte)为单位的.上面说的gen-fmt和dev-fmt可以说最终是指明了哪一个sector,那么从sector到offset的关系很容易就可以猜想,是要乘以每sector的字节数,这里的geo指出是4096个字节,因此就是乘以4096也就是左移12位.
so:

gen-fmt --> offset
uint64_t nvm_addr_gen2off(struct nvm_dev *dev, struct nvm_addr addr)
{
    return nvm_addr_gen2dev(dev, addr) << dev->ssw;
}

至于这里为啥要先转成dev-fmt,这里我也有些不理解。
先说下不理解的根源是与我们的直觉不符,我们直觉上应该:
从意义上,offset指定的是某个sector的某个byte。地址应该是先转成第x个sector,并把这个x乘以4096才对,刚才的x并不等于dev-fmt的addr。
我给此的解释是这样的:
从下面的fmt-mask可以看出pg与blk的位置对换了,但这就是dev-fmt你无法选择。事实上dev-fmt想把lun放在最右边你也没办法阿~科科,我可以说机器的地址线的这几列老子就是解释成lun你想怎样?
但总和上不管把dev的地址的某几位解释成什么,offset的总量是固定的,只是对于某个ofs,特定的解释方式可能得到不同的某个sector中的某个byte.
但只要解释成ofs和从ofs解释回dev的方式固定,得到的特定byte是自恰的.

fmt-mask {
  ch(0000000000000000000000000000000000000000000000000000000000000000),
 lun(0000000000000000000000000000000000000000011000000000000000000000),
  pl(0000000000000000000000000000000000000000000100000000000000000000),
 blk(0000000000000000000000000000000000000000000000000000111111111111),
  pg(0000000000000000000000000000000000000000000011111111000000000000),
 sec(0000000000000000000000000000000000000000000000000000000000000000)
}

lba-format address:这个就同理,刚才的单位是byte,这里因为一些标准的缘故,lba貌似是指最初的rotating disk的sector的单位(512字节),因此从offset转到lba就是再除以512,也就是左移9位.

gen-fmt --> lba(#define NVM_UNIVERSAL_SECT_SH 9 : see nvm.h)
uint64_t nvm_addr_gen2lba(struct nvm_dev *dev, struct nvm_addr addr)
{
    return nvm_addr_gen2off(dev, addr) >> NVM_UNIVERSAL_SECT_SH;
}

最后的最后:一些使用nvm_addr的quick example.

  1. Iteration over all sectors : see test_addr_conv.c
    suppose geo here is like: (as what we've got in last blog)
geo {
 nchannels(1), nluns(4), nplanes(2),
 nblocks(2044), npages(256), nsectors(1),
 page_nbytes(4096), sector_nbytes(4096), meta_nbytes(16),
 tbytes(17146314752b:16352Mb),
 vpg_nbytes(8192b:8Kb),
 vblk_nbytes(2097152b:2Mb)
}

now,iterate all sectors we have:(sector is THE MINIMAL granularity one can access into a disk)

 size_t tsecs = geo->nchannels * geo->nluns * geo->nplanes * geo->nblocks * geo->npages * geo->nsectors;
 for (int sec = 0; sec < tsecs; ++sec) {
    struct nvm_addr expected;
    expected.ppa = 0;
    expected.g.sec = sec % geo->nsectors;//this is how we get a PPA(by hand-calculating)
    expected.g.pg = (sec / geo->nsectors ) % geo->npages;//:=
    expected.g.blk = ((sec / geo->nsectors) / geo->npages ) % geo->nblocks;
    expected.g.pl = (((sec / geo->nsectors) / geo->npages ) / geo->nblocks) % geo->nplanes;
    expected.g.lun = ((((sec / geo->nsectors) / geo->npages ) / geo->nblocks) / geo->nplanes) % geo->nluns;
    expected.g.ch = (((((sec / geo->nsectors) / geo->npages ) / geo->nblocks) / geo->nplanes) / geo->nluns) % geo->nchannels;
    
    //do something with that sector_number.
 }
  1. nvm_addr赋值.
#include 
struct nvm_addr a,b;
b.ppa = 0;//所有域赋为0
a.ppa = b.ppa;//把b表示的地址赋给a

你可能感兴趣的:([Qemu OpenChannelSSD] Address Issues)