Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Mar 2022 15:34:15 -0700
From:      Bakul Shah <bakul@iitbombay.org>
To:        Mario Marietto <marietto2008@gmail.com>
Cc:        Chuck Tuffli <chuck@tuffli.net>, jason@tubnor.net, FreeBSD virtualization <freebsd-virtualization@freebsd.org>
Subject:   Re: bhyve NVMe 1.4 support
Message-ID:  <5CBC2D64-9CAC-4B88-97AA-D9906CE0517E@iitbombay.org>
In-Reply-To: <CA%2B1FSigP62M=jQp2ajcOSbFw3dGhyRr9RL2D8yhecT7Fp_oUgA@mail.gmail.com>
References:  <CAM0tzX1W1Do=uqA3PONyksY4dmob%2BZMi-ib7aECVx6AH3XW6Pw@mail.gmail.com> <00bf01d80104$e6ba5de0$b42f19a0$@tubnor.net> <CAM0tzX1EdQfTDUMU1dNtQHxG9SB3VzNP5UGmHuiHCY5HsxL2QA@mail.gmail.com> <CAM0tzX1qJOuqJWv_04oMvTqQrmLNQf8O%2B8PJ6cjLyh9bLqRmNQ@mail.gmail.com> <082b01d80697$64e95030$2ebbf090$@tubnor.net> <CA%2B1FSiijy0YjX0Nju9kRAY8hsYc42Y70V3tu-RfqCnaRhzLa8A@mail.gmail.com> <CAM0tzX3SCOS2nOKaODVF2TCTOY_5F5sdqELA666uFRZ=ZreXpg@mail.gmail.com> <CA%2B1FSijNU7Nn9UZujU%2BCLgJkaYFrbfdu37RT7s_r%2Be08AMG0Pw@mail.gmail.com> <CAM0tzX03Sw23acPW8ZRcwXO2Rze12OuvBoO6QSUfePpfBdrbWA@mail.gmail.com> <CA%2B1FSijNKxNsHqHCTPE3swh_5ePc-_jtNHFtmBTbUbauEDPung@mail.gmail.com> <CAM0tzX3mG%2BmWvjXrR-5GzTN66y3=PpBqAT_6Gxddc5Kqwtm0qw@mail.gmail.com> <CA%2B1FSiiQKET%2BJqSdjo5py-sQgV4txM5QEBXCMA-98eN2Sjq8Gw@mail.gmail.com> <CAM0tzX1QhY1%2By5aM6LCUtK5LC1fRq=JF084LoP4gNMCHOsXKAg@mail.gmail.com> <CA%2B1FSiiMyP586_FCOi0cJNubWLYPpkFifuMkj=qNq6uGcaTk6A@mail.gmail.com> <CAM0tzX1aAVOjF4xjQKEjxU9Xo8Mdskd4bchVB=w6LE9m-=e0hg@mail.gmail.com> <CA%2B1FSigP62M=jQp2ajcOSbFw3dGhyRr9RL2D8yhecT7Fp_oUgA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 2022, at 3:11 PM, Mario Marietto <marietto2008@gmail.com> wrote:
> 
> -s 2,nvme,/dev/nvd0 \

AIUI, this 'nvme' means bhyve will *emulate* an NVME device
and it will treat whatever is given to it (/dev/nvd0) as just
dumb storage. It doesn't care if /dev/nvd0 is an NVME device.
So commands such as nvmecontrol identify etc. in the *guest*
won't be passed through to /dev/nvd0 through to it. If you
run nvmecontrol identify under ktrace in the guest, you will
see something like

  3657 nvmecontrol NAMI  "/dev/nvme0ns1"
  3657 nvmecontrol RET   openat 3
  3657 nvmecontrol CALL  ioctl(0x3,NVME_GET_NSID,0x1245f31731a8)
  3657 nvmecontrol RET   ioctl 0
  3657 nvmecontrol CALL  close(0x3)
  3657 nvmecontrol RET   close 0
  3657 nvmecontrol CALL  openat(AT_FDCWD,0x1245f3173260,0<O_RDONLY>)
  3657 nvmecontrol NAMI  "/dev/nvme0"
  3657 nvmecontrol RET   openat 3
  3657 nvmecontrol CALL  ioctl(0x3,NVME_PASSTHROUGH_CMD,0x1245f3173250)
  3657 nvmecontrol RET   ioctl 0
  3657 nvmecontrol CALL  close(0x3)

These ioctls will *not* be passed on the real /dev/nvd0 in the host
so they are *not* going to return the same information.

If you want to talk to the real nvme device from a guest, you have
to use a passthrough device. Though I don't know how well this works
(or if at all).



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5CBC2D64-9CAC-4B88-97AA-D9906CE0517E>