Windows 10 guests fail to boot when attempting to passthrough network card

[Rodney W. Grimes]

> Yeah, that triggers a barf with error 2:
> mmio_rb_lookup: barf ENOENTerror is 2
> mr.name is passthru-pci-5
> mr.flags is 0
> mr.arg2 is 0
> mr.base is 18446744073709027328
> mr.size is 524288
> Assertion failed: (error == 0), function modify_bar_registration, file
> /usr/src/usr.sbin/bhyve/pci_emul.c, line 510.
> 
> Interestingly enough, after we talked I simply commented out the assert at
> 504 in pci_emul.c and Windows booted fine and can see the Chelsio card with
> both interfaces. I'm not sure if it would fall over once I started actually
> using it or not.

I would go forward with testing, worst that happens is a host panic.


> `nap
> 
> 
> On Sat, May 18, 2019 at 4:06 PM Rodney W. Grimes <
> freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> 
> > > I have noticed that Windows 10 guests fail to boot when attempting to
> > pass
> > > through a network card. I believe I have observed this with both cxgbe
> > > (t580) and mlx5en cards, but only have a cxgbe to test with now. Without
> > > passthrough, the Windows 10 guest boots and operates normally.
> > >
> > > FreeBSD guests (12.0-RELEASE) have no issue when booting with the cxgbe
> > > card passed through - I can kldload cxgbe and I get both cxl ports
> > showing
> > > up in the FreeBSD guest.
> > >
> > > I have tested this with both 12.0-RELEASE and head (13-CURRENT r347883)
> > as
> > > the host OS with no change in behavior. The bhyve output is:
> > > Unhandled ps2 keyboard command 0x02
> > > Unhandled ps2 keyboard command 0x02
> > > Assertion failed: (error == 0), function modify_bar_registration, file
> > > /usr/src/usr.sbin/bhyve/pci_emul.c, line 504.
> > > fbuf frame buffer base: 0x943600000 [sz 16777216]
> > >
> > > Two main suggestions from discussions at BSDCan this week were:
> > > - Capture pciconf -lvb from the FreeBSD guest
> > > - Add some printf to pci_emul.c to capture some values when there is an
> > > error
> > >
> > > I've captured the above, and a lot of other relevant info, in a Google
> > Doc
> > > here (too big to post directly):
> > >
> > https://docs.google.com/document/d/1t-UVIO9Aq0TPUFHyo1nVscqaW1LoPuNhfLPitL8oeTs/edit?usp=sharing
> > >
> > > `nap
> >
> > To confirm what I see from looking at your data could you tell me if this
> > patch triggers a barf?
> >
> > --- mem.c.orig  2019-05-18 20:04:26.707995000 +0000
> > +++ mem.c       2019-05-18 20:04:02.205119000 +0000
> > @@ -97,6 +97,7 @@
> >                 return (0);
> >         }
> >
> > +printf("mmio_rb_lookup: barf ENOENT");
> >         return (ENOENT);
> >  }
> >
> > --
> > Rod Grimes
> > rgrimes at freebsd.org
> >
> 
> 
> -- 
> Nick Principe
> Performance Engineering Supervisor
> iXsystems, Inc.
> Ph: (408) 943-4100 x341
> Fx: (408) 943-4101

-- 
Rod Grimes                                                 rgrimes at freebsd.org