I'm looking for some NVMM developer who wants to join a special group for improving qemu and nvmm
Hello to everyone. My name is Mario. I love the hypervisors,even if I'm only a humble tester of patch and code. In the recent past I've made available my PC to Corvin and Peter and we have been able to allow the passthrough of my RTX 2080 ti on a Linux VM in bhyve. It has been a nice experience for me. I've learned a lot from them. I've enjoyed the experience so much that I want to repeat it. I'm trying to create a small group of developers to work on adding the VT-D support for NVMM. I would like to create a mixed group : a bhyve developer,a DFLY developer and a NetBSD developer,since the NVMM code is shared between DFLY and NetBSD and Corvin,a Bhyve developer has a deep knowledge of bhyve and can learn and help. For the moment I've asked Corvin and Aaron. Does anyone else want to join ? Or do you know some other developer that wants to join the project ? We could start to work together,trying to fix this bug : http://mail-index.netbsd.org/netbsd-bugs/2022/01/11/msg074018.html and then we can start to plan how to add the VT-d support for NVMM. -- Mario.
Re: procfs files vs symlink
On Tue, Jan 11, 2022 at 08:00:53PM +, David Holland wrote: > On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote: > > The attached diff changes the procfs behavior to match the linux one, for > > linux processes: > > comore:/home/bouyer>ls -l /proc/self/fd/ > > total 1 > > crw--w 1 bouyer tty5, 0 Jan 11 11:08 0 > > crw--w 1 bouyer tty5, 0 Jan 11 11:08 1 > > crw--w 1 bouyer tty5, 0 Jan 11 11:08 2 > > lr-xr-xr-x 1 bouyer staff 512 Jan 11 11:08 3 -> /home/bouyer > > > > ls: /proc/self/fd//4: Invalid argument > > lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 4 > > What causes that EINVAL? I'm not sure (somneone suggested that the file descriptor has been closed when ls tries to fstat() it, but I can't confirm this). Anyway, it happens also without my patch - see my mail on current-users about the linux binary issue. > > also beware -- the linux world expects regular files to have canonical > paths, and that's just not true elsewhere and can't really be papered > over. I didn't check all the cases, but it's enough to make my binaries run. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: procfs files vs symlink
On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote: > The attached diff changes the procfs behavior to match the linux one, for > linux processes: > comore:/home/bouyer>ls -l /proc/self/fd/ > total 1 > crw--w 1 bouyer tty5, 0 Jan 11 11:08 0 > crw--w 1 bouyer tty5, 0 Jan 11 11:08 1 > crw--w 1 bouyer tty5, 0 Jan 11 11:08 2 > lr-xr-xr-x 1 bouyer staff 512 Jan 11 11:08 3 -> /home/bouyer > > ls: /proc/self/fd//4: Invalid argument > lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 4 What causes that EINVAL? also beware -- the linux world expects regular files to have canonical paths, and that's just not true elsewhere and can't really be papered over. -- David A. Holland dholl...@netbsd.org
Re: procfs files vs symlink
On Tue, Jan 11, 2022 at 11:34:45AM +0100, Martin Husemann wrote:
> On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote:
> > +static inline bool
> > +procfs_proc_is_linux_compat(void)
> > +{
> > + const char *emulname = curlwp->l_proc->p_emul->e_name;
> > + return (strncmp(emulname, "linux", 5) == 0);
> > +}
>
> Not a big deal, but wouldn't it be better to give this behaviour a
> symbolic name and use a bit in e_flags for it? This seems to be mostly
> unused so far (or I did something wrong when searching for it).
Maybe, but there's already code like this in procfs. I just cut-n-pasted
it in a function for my need (and we could use this function in other
places in procfs as well, but this would be a different commit)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: procfs files vs symlink
On Tue, Jan 11, 2022 at 11:10:24AM +0100, Manuel Bouyer wrote:
> +static inline bool
> +procfs_proc_is_linux_compat(void)
> +{
> + const char *emulname = curlwp->l_proc->p_emul->e_name;
> + return (strncmp(emulname, "linux", 5) == 0);
> +}
Not a big deal, but wouldn't it be better to give this behaviour a
symbolic name and use a bit in e_flags for it? This seems to be mostly
unused so far (or I did something wrong when searching for it).
Martin
Re: procfs files vs symlink
On Fri, Jan 07, 2022 at 03:20:04PM +0100, Manuel Bouyer wrote:
> Hello
> I'm trying to get a linux binary to run on NetBSD, as stated in this thread
> http://mail-index.netbsd.org/current-users/2022/01/06/msg041891.html
>
> Now I hit an issue where the linux process does a readlink() on a procfs
> file and gets EINVAL.
> It seems that this is because, on linux all files in /proc//fd/ are
> symlinks, while on NetBSD they are some kind of hard links.
> E.g. on linux:
> bip:/dsk/l1/misc/bouyer/HEAD/clean/src>ls -l /proc/$$/fd/
> total 0
> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 0 -> /dev/null
> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 1 -> /dev/null
> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 15 -> /dev/pts/11
> lrwx-- 1 bouyer ita-iatos 64 Jan 7 14:13 16 -> /dev/pts/11
> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 17 -> /dev/pts/11
> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 18 -> /dev/pts/11
> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 19 -> /dev/pts/11
> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 2 -> /dev/null
>
> On NetBSD:
> armandeche:/local/armandeche1/bouyer>/emul/linux/bin/ls -l /proc/$$/fd/
> total 0
> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 15
> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 16
> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 17
>
> Any idea on how to properly fix it ?
The attached diff changes the procfs behavior to match the linux one, for
linux processes:
comore:/home/bouyer>ls -l /proc/self/fd/
total 1
crw--w 1 bouyer tty5, 0 Jan 11 11:08 0
crw--w 1 bouyer tty5, 0 Jan 11 11:08 1
crw--w 1 bouyer tty5, 0 Jan 11 11:08 2
lr-xr-xr-x 1 bouyer staff 512 Jan 11 11:08 3 -> /home/bouyer
ls: /proc/self/fd//4: Invalid argument
lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 4
comore:/home/bouyer>/emul/linux/bin/ls -l /proc/self/fd/
total 0
lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 0 -> /dev/ttyp0
lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 1 -> /dev/ttyp0
lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 2 -> /dev/ttyp0
lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 3 -> /
and my linux binaries seems to work properly now
would it be OK to commit ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: sys/miscfs/procfs/procfs.h
===
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs.h,v
retrieving revision 1.80
diff -u -p -u -r1.80 procfs.h
--- sys/miscfs/procfs/procfs.h 29 Apr 2020 07:18:24 - 1.80
+++ sys/miscfs/procfs/procfs.h 11 Jan 2022 10:06:44 -
@@ -213,6 +213,14 @@ struct mount;
struct proc *procfs_proc_find(struct mount *, pid_t);
bool procfs_use_linux_compat(struct mount *);
+
+static inline bool
+procfs_proc_is_linux_compat(void)
+{
+ const char *emulname = curlwp->l_proc->p_emul->e_name;
+ return (strncmp(emulname, "linux", 5) == 0);
+}
+
int procfs_proc_lock(struct mount *, int, struct proc **, int);
void procfs_proc_unlock(struct proc *);
int procfs_allocvp(struct mount *, struct vnode **, pid_t, pfstype, int);
Index: sys/miscfs/procfs/procfs_vfsops.c
===
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs_vfsops.c,v
retrieving revision 1.110
diff -u -p -u -r1.110 procfs_vfsops.c
--- sys/miscfs/procfs/procfs_vfsops.c 28 Dec 2020 22:36:16 - 1.110
+++ sys/miscfs/procfs/procfs_vfsops.c 11 Jan 2022 10:06:44 -
@@ -343,7 +343,8 @@ procfs_loadvnode(struct mount *mp, struc
* We make symlinks for directories
* to avoid cycles.
*/
- if (vxp->v_type == VDIR)
+ if (vxp->v_type == VDIR ||
+ procfs_proc_is_linux_compat())
goto symlink;
vp->v_type = vxp->v_type;
break;
Index: sys/miscfs/procfs/procfs_vnops.c
===
RCS file: /cvsroot/src/sys/miscfs/procfs/procfs_vnops.c,v
retrieving revision 1.220
diff -u -p -u -r1.220 procfs_vnops.c
--- sys/miscfs/procfs/procfs_vnops.c8 Dec 2021 20:11:54 - 1.220
+++ sys/miscfs/procfs/procfs_vnops.c11 Jan 2022 10:06:44 -
@@ -1142,7 +1142,8 @@ procfs_lookup(void *v)
fvp = fp->f_vnode;
/* Don't show directories */
- if (fp->f_type == DTYPE_VNODE && fvp->v_type != VDIR) {
+ if (fp->f_type == DTYPE_VNODE && fvp->v_type != VDIR &&
+ !procfs_proc_is_linux_compat()) {
vref(fvp);
closef(fp);
procfs_proc_unlock(p);
@@ -1659,7 +1660,8 @@ procfs_readlink(void *v)
switch (fp->f_type) {
case DTYPE_VNODE:
vxp = fp->f_v
