Re: GPU passthrough: mixed success on Linux, not yet on Windows
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 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
> 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.75299 +0100
>> +++ mem.c 2019-03-02 22:27:14.500906000 +
>> @@ -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, _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 wrote:
>>
>>> Hi Robert:
>>>
>>> On Sun, Mar 17, 2019 at 04:22:29PM +, 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"
Re: GPU passthrough: mixed success on Linux, not yet on Windows
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.75299 +0100
> +++ mem.c 2019-03-02 22:27:14.500906000 +
> @@ -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\n", new_element->mr_base,
> new_element->mr_end);
> +
> if (overlap != NULL) {
> -#ifdef RB_DEBUG
> - printf("overlap detected: new %lx:%lx, tree %lx:%lx\n",
> - new->mr_base, new->mr_end,
> +//#ifdef RB_DEBUG
> + printf("overlap detected: new_element %lx:%lx, tree
> %lx:%lx\n",
> + 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, _rb_root, entry);
>
> + printf("unregister: %lx:%lx\n", 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.\n", err,
> + memp->base, memp->base + memp->size );
> +
> + return 0;
> + //return (err);
> }
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 28 March 2019 22:02, Ruslan Bukin wrote:
>
> > Hi Robert:
> >
> > On Sun, Mar 17, 2019 at 04:22:29PM +, 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"
Re: running FreePBX SNG7 Official Distro
Victor Sudakov wrote: > > > > I'll look into the VirtualBox directory tomorrow and report here. > > > > > > I searched through my disk and was unable to find a persistant efivars > > > storage in my VirtualBox 6.0 installation. > > > > > > A Google search reveals some articles (rather dated I must admit) > > > stating that VirtualBox does not support NVRAM emulation for storing efi > > > variables: > > > > > > https://www.virtualbox.org/ticket/14279 > > > https://forums.virtualbox.org/viewtopic.php?t=61970 > > > > My quick search turns up: > > https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/DevEFI.cpp > > My quick search turns up that it's there in the code but it is not > used, or it is not enabled by default, whatever (it's written in > https://forums.virtualbox.org/viewtopic.php?p=402022=02333b87a8a2bba99383449fc08ca317#p402022 > ) > A fairly recent note: https://www.centos.org/forums/viewtopic.php?p=278745=e52bd17e42d2530f496749054b0cc174#p278745 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
