I'm losing track of all the scenarios a bit here but as I mentioned before I have a motherboard with PCI and VT-d but I'm very doubtful that the BIOS will support the required isolation for passthrough as it definitely predates that really being something that end users were into. I may be wrong on the 6700K processor too, I think that machine in on my electronics workbench which means the one in the box is likely 4700K. Still has VT-d though, but even earlier.
On the plus side, I just realised that if I'm to put the spare GPU I have in my main gaming machine then I don't need the missing power cable as it already has one. I'm posting now with both GPUs installed and I know this motherboard has excellent isolation properties if I can remember how to enable it in the BIOS.
So when I get some time I can do some experiments and potentially add some logs etc., but I'll only do so if it looks like it adds value otherwise too much noise is not a good thing!
[EDIT] Forgot to mention that I also have a PCI to PCIe bridge to allow a PCIe card to be plugged into PCI. I was about to send it back as it's the wrong way round (I wanted to plug PCI into PCIe). I'm not sure I really see the point in me keeping it because IF the motherboard with PCI will allow isolation (doubtfull) then that board has PCIe. The only reason to put it into a bridge would be to test the bridge. Like I say, too many scenarios here, I'm losing track!
it is possible according to your experience that somehow it is possible to use "NPCAP" inside "qemu"
I'm sorry but it's been years and wine has improved a lot I was wondering if somehow it is possible to interact with NPCAP configured with "wine" via qemu
"Or remains isolated only inside "wine" eventually"
It's actually the Linux kernel that does the isolation into MMU groups. So as long as your motherboard and processor support VT-d then you're good to go.
No problem - I'll try the script but my Ubuntu is 22.04 and I don't desperately fancy reinstalling. Not really an issue though, I've done all of this several years ago on this machine, I just need to dig out my notes and remember how.
Incidentally, on this machine at least, it's possible in the BIOS to have virtualisation enabled (whatever AMD refer to VT-d as) but not have IOMMU isolation enabled. I'll figure it. But maybe not today as I need to go out soon.
[EDIT] Never mind - that was easy, the script worked and my secondary GPU is isolated to vfio-pci
if the group is the '0d' in '0d:00.0' then no. Apart from '0d:00.1' which is the HD Audio part of the GPU (also bound to virtio).
I specifically purchased this motherboard at the time based on it's ability to isolate and from memory I believe it puts every device in it's own group. This was pre-pandemic though so my memory of it isn't great.
it is possible according to your experience that somehow it is possible to use "NPCAP" inside "qemu"
I don't know what is NPCAP in relation to WinUAE and I have absolutely no experience with Windows or Wine, sorry. But I think you're overcompicating things and trying to apply concepts to QEMU where it's not applicable. Instead you should find out why communication through -netdev hostfwd or -netdev tap is not working for you. You may just be configuring it incorrectly. Just forget about VMWare and WinUAE and think QEMU, we don't have vmnet8 and NPCAP here, we have slirp or tap which probably do the same but differently.
Thanks for the reply. But I just can't get it to work
But I'm stubborn and sooner or later I'll find a solution
i know we've talked about this before i was wondering "ne2k_pci" can be improved in the future. Because it's the "RTL 8029" driver that maybe is better for these things.
@all
the problem is not the internet connection by AmigaOS with qemu I can connect in a thousand different ways.
Does anyone want to test if AmiCygnix works on their configuration ?
OK, I'm out of time for now, need to go. I need to read through the thread again tonight. My suspicion is that this isn't going to work as QEMU spits out a crash on startup citing something about 32BIT addresses and an unimplemented OPCode.
In OS4 (I have sm501 device as well at the moment) it does show the PCI card as "Working" in HWInfo but I'm guessing that means little more than it knows that it's there.
This is my RX580 incidentally with 8GB of memory on board. Just giving it a try because it was there sat in a box doing nothing.
Looks like the firmware part may be OK. In the above it shows it recognised the 64 bit BARs and also mapped them according to assigned addresses
That could be the problem, maybe 32 bit PCI-only (classic Amiga, AmigaOne and Pegasos2) kernels don't support 64 bit BARs but only 32 bit ones and only the Sam, X1000, X5000, etc. kernels with PCIe support include support for 64 bit BARs. The difference could be that U-Boot configures them as 32 bit m BARs instead of 64 bit x BARs and that way the AmigaOS kernel can use them. The U-Boot pci output on an AmigaOne with a 64 bit BAR card installed could be used to check it, but OTOH the U-Boot pci output may not include enough information.