That’s good to know, I wasn’t aware of that. Separately I have found a number of GPUs taint their ROMs after they initialization, preventing reinitialization. There is a related problem too with video BIOS shadowing if you want to use the primary GPU for pass through. I am not sure if the D3 reset can fix that.
I understand that qemu has an option to present a pre-captured pristine ROM from file as the GPU’s ROM to the guest. I am looking at whether this is a possible approach in bhyve. On Tue, Apr 9, 2019 at 15:40, Nick Wolff <darkfiber...@gmail.com> wrote: > Robert, > > I'm hoping that the set of commits done for > https://reviews.freebsd.org/D19646 will fix the pcie reset problems. > Apparently pcie wasn't auto retraining after reset. I don't know if connected > to that review but wanted to let you know. > > On Wed, Apr 3, 2019 at 7:42 PM Robert Crowston via freebsd-virtualization > <freebsd-virtualization@freebsd.org> wrote: > >> To get Windows to boot I think the only hacks I needed were in bhyve/mem.c >> (this is not production ready!) >> >> Diff'd against 12.0-release >> >> -- /tmp//sh-np.vFXFJd 2019-04-04 00:29:32.752990000 +0100 >> +++ mem.c 2019-03-02 22:27:14.500906000 +0000 >> @@ -101,20 +101,22 @@ >> } >> >> static int >> -mmio_rb_add(struct mmio_rb_tree *rbt, struct mmio_rb_range *new) >> +mmio_rb_add(struct mmio_rb_tree *rbt, struct mmio_rb_range *new_element) >> { >> struct mmio_rb_range *overlap; >> >> - overlap = RB_INSERT(mmio_rb_tree, rbt, new); >> + overlap = RB_INSERT(mmio_rb_tree, rbt, new_element); >> >> + printf("mmio_rb_add: %lx:%lx ", new_element->mr_base, >> new_element->mr_end); >> + >> if (overlap != NULL) { >> -#ifdef RB_DEBUG >> - printf("overlap detected: new %lx:%lx, tree %lx:%lx ", >> - new->mr_base, new->mr_end, >> +//#ifdef RB_DEBUG >> + printf("overlap detected: new_element %lx:%lx, tree %lx:%lx >> ", >> + new_element->mr_base, new_element->mr_end, >> overlap->mr_base, overlap->mr_end); >> -#endif >> +//#endif >> >> - return (EEXIST); >> +// return (EEXIST); >> } >> >> return (0); >> @@ -336,6 +338,8 @@ >> assert((mr->flags & MEM_F_IMMUTABLE) == 0); >> RB_REMOVE(mmio_rb_tree, &mmio_rb_root, entry); >> >> + printf("unregister: %lx:%lx ", mr->base, mr->base+mr->size); >> + >> /* flush Per-vCPU cache */ >> for (i=0; i < VM_MAXCPU; i++) { >> if (mmio_hint[i] == entry) >> @@ -348,7 +352,12 @@ >> if (entry) >> free(entry); >> >> - return (err); >> + if (err) >> + fprintf( stderr, "Unregister mem errno %d for range %lx:%lx. >> ", err, >> + memp->base, memp->base + memp->size ); >> + >> + return 0; >> + //return (err); >> } >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Thursday, 28 March 2019 22:02, Ruslan Bukin <b...@bsdpad.com> wrote: >> >>> Hi Robert: >>> >>> On Sun, Mar 17, 2019 at 04:22:29PM +0000, Robert Crowston via >>> freebsd-virtualization wrote: >>> >>> > Is it worth me continuing to hack away at these problems---of course I'm >>> > happy to share anything I come up with---or is there an official solution >>> > to GPU support in the pipe about to make my efforts redundant :)? >>> >>> Could you share your patch/hacks somewhere? >>> I would like to try it with AMD graphics card and Windows. >>> >>> Ruslan >> >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscr...@freebsd.org" _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"