GPU passthrough: mixed success on Linux, not yet on Windows

[Robert Crowston]

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 <darkfiberiru at 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 at 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 <br at 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"