What the fastest possible x64 emulation way of OS4 today ?

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!

@balaton
I haven't used "wine" for years
once installed:

sudo aptupdate
sudo dpkg --add-architecture i386
sudo mkdir -pm755 /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubun ... ammy/winehq-jammy.sources
sudo aptupdate
sudo apt install --install-recommends winehq-stable
wine --version
winecfg

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"

Thank you

@MartinW

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.

@geennaam

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

@MartinW

OK, so no other devices in your iommu group?

@geennaam

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.

@white
Quote:

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.

@MartinW

No, that's not the group.

@geennaam

Ah, ok - same result though, only the GPU and it's embedded Audio are in group 30

@MartinW

OK, then you are good to go.

@balaton

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 ?

Thank you.

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.

@balaton
Quote: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.

@joerg

The sam440 doesn't have PCIe.

@geennaam
Are there different kernels for Sam440 and Sam460, or only a single Sam4x0 kernel?

Additionally it's U-Boot vs. SmartFirmware, Radeon HD cards even work in an AmigaOne XE with a PCI to PCIe bridge.

@joerg

I very much doubt this but I guess that I can find out

@geennaam
U-Boot output of "pci <bus> long" on a real Sam440 with PCIe card might help as well.

At least the 460cr isn't a 460 CPU but a 440 one, therefore mixing 440 and 460 firmware/kernel/emulation shouldn't be a big problem.

@joerg

As far as I know, the 460cr is using exactly the same amcc Ppc460ex cpu.

Ony the sam440 ep and flex have the ppc440ep cpu.

Tried to boot qemu with my sam440 cd but that results on a kernel panic.

@geennaam
AMCC 460
The PowerPC 460EX and 460GT from AMCC are, despite their name, processors with the 440 core

@joerg

Yes the processor core is the same but the SoC and memory map is different. Hence the kernel panic.