@All Soo, after derfs with help of modern AI magic created Virtio9PFS-handler : https://github.com/derfsss/Virtio9PFS-handler (so you have ability to use shared directories and not the sucky fat-stick-way where you need to reboot always to see changes), and after smarkusg confirmed that it works on linux and macos, i tried to make it work on windows too, with pegasos2 emulation, just to realize that it has no -virtfs (p9) used for those shares..
First idea was to use WSL2 build, which i did, just to realize that because of layers in between it's still visibly slower than native win32 build of qemu. So no go.
Then doing some research to find out that there were some unofficial patches to make virtfs working on native windows targets too, but for older versions of qemu. So i took latest 10.2.1, and started applying those patches, firstly some older ones, then newer ones, but of course conflicts and stuff, but in the end succeeded, and TADAM:
(click open in new window for full size):
And it indeed works! Everything ultra fast, everything immediately refreshes and can be seen in realtime. Speed awesome, just gigabytes per second, and i can forget now as a bad dream this fat32-ugly way.
So thanks to derfs (and of course those AIs who can help us now), to smarkusg for tests, and for somebody's patches for win32.
PS. The funny thing is, once i made it all work, i found out that on github there is one man who is doing exactly the same, and made ready to use builds with integrated virtfs-p9 patches, damn! But at least i spent a day for learning purposes about qemu :)
@kas1e It's great that you managed to get it running on Windows and shared all the information on how to do it – congratulations
Regarding Pegasos2. There is an entry in README... "Pegasos2 (modern VirtIO) is implemented but not yet validated. Use at your own risk." I would also like to add that Virtio9PFS-handler requires AmigaOS 4.1 FE U3. I checked it out of curiosity to remake the AmigaOS 4.1 FE installation CD disc for AmigaOne and QEMU containing Virtio9PFS-handler. It didn't work. I installed a clean system and updated from U1. .. It worked with U3.
EDIT: My mistake was the Virtio SCSI driver, not the Virtio9PFS-handler. Sorry for the mistake – I deleted the unnecessary entry.
@smarkusg Can you on linux/macos copy amiga executable to os4 to shared dir, and then, do "protect" on this file to set executable bit ? For me it dind't and says "unknown paket type", and i had to copy it to ram: to make protect work and mark file as executable
@kas1e Of course you can't set Amiga protection bits on non-Amiga filesystems the same way you can't set Unix protection bits on FAT because there's no place to store it. But I wonder how are the protection bits stored on the install ISO? Maybe there's a mapping to Unix bits that's stored in RockRidge extensions? But even with that you may get problems on Windows where you don't even have Unix bits on a Windows filesystem.
@kas1e I checked on macOS. The files I move to “shared” are created with executable bits (all attributes). Host (macOS) I am unable to change the “bits” for the native file system for AOS, and it is not set. “mapped-xattr: Some of the file attributes like uid, gid, mode bits and link target are stored as file attributes. This is probably the most reliable and secure option” https://wiki.qemu.org/Documentation/9psetup
EDIT: @balaton I already wrote about this. I didn't notice. I'm leaving the post for screenshots.
On fat-usb stick it works (i mean protect +e) because fat.handler seems simple silently ignore error, instead of return error, so you can set protect, but then, of course, it didn't saves, didn't survive reboot, etc.
Then, i made a test by copy any file with executable bit set to the SHARED directory via new handler, and +e bit survive reboot ! So that mean it saves for sure on this FS.
After some tinkering, find out that it saves in Windows NTFS Alternate Data Stream named user.virtfs.mode alongside the file, see:
The ADS content 0xFD 0x81 = 0x81FD = S_IFREG | 0775 — the x bit is present exactly where expected. For test.txt (where protect +e failed), no user.virtfs.mode ADS exists at all — QEMU has nowhere to store the mode, and the 9P Setattr request fails.
So, asked AI to create simple script which via powershell set set the necessary fields if they not present, or change them if present, and tadam, see:
root@DESKTOP-E507GTH:/mnt/d/shared# python3 protect.py test3.txt +e
(no existing ADS, using default mode 0x81B6)
test3.txt: set +e (mode=0x81FF)
root@DESKTOP-E507GTH:/mnt/d/shared# python3 protect.py test3.txt -e
test3.txt: cleared -e (mode=0x81B6)
root@DESKTOP-E507GTH:/mnt/d/shared# python3 protect.py test3.txt +e
test3.txt: set +e (mode=0x81FF)
root@DESKTOP-E507GTH:/mnt/d/shared# python3 protect.py test3.txt +e
test3.txt: set +e (mode=0x81FF)
root@DESKTOP-E507GTH:/mnt/d/shared#
And it works. I can see how bit sets/changes from OS4 side in realtime, yeahoo !! I even made small C tool which now just doing same, and can be running from windwos/wsl/whatever.
Now, while now i can easy do after any os4 compile call of this script/tool over binary to make it be +e , but probably fix in the Handler still need it to make "protect" command to work. All we need is in fuse_ops.c:
And register callback in V9P_FillOperations with "ops->chmod = v9p_chmod;", then qemu when recieve P9_Setattr with P9_SETATTR_MODE create user.virtfs.mode AD (if there none), and if there any, just refresh with new data.
I.e. currently in handler "ops->chmod = NULL", and this mean:
Even if file with ADS, protect +e mean "packet request type unknown", and file without ADS, the same "packet request type unknown" too.
EDIT: fixed code a bit for new function, and tested: yes, everything works !
ps. if anyone need it can share both python script and C code to set amiga protect bit from windows size.
As i understand now, -virtfs issue is not windows related, but pegasos2 related in whole (same issue smarkusg have on linux and macos). I.e. -vritfs mean legacy mode, while -fsdev seems "modern" one (at least that how i understand it). Can't be sure but that mean some changes in pegasos2 way need to be done for legacy support (not big deal of course, as it works like it works, but nothing is perfect as always:) )
@kas1e I don't know virtio but I doubt -virtfs would be legacy. According to the docs smarkusg linked (which seem quite outdated but maybe still there's some truth in it) it should be the same as -device virtio-9p-pci which should support both legacy and modern but maybe the driver need to do something to switch it to modern mode or is that the default?
@kas1e You also fixed a bug that I hadn't noticed before. I always copy files with AmigaShell or Mycommander. Today, when I tried to move the entire program in Workbench (moving the icon to the SHARED disk), I got an error. After updating to “0.4.0-beta,” the error no longer appears. I checked on PEG2 Linux and macOS. Thank you.
As i understand now, -virtfs issue is not windows related, but pegasos2 related in whole (same issue smarkusg have on linux and macos). I.e. -vritfs mean legacy mode, while -fsdev seems "modern" one (at least that how i understand it). Can't be sure but that mean some changes in pegasos2 way need to be done for legacy support (not big deal of course, as it works like it works, but nothing is perfect as always:) )
If I understand the documentation correctly, this should currently be enforced. As @balton wrote, -device virtio-9p-pci should work in automatic negotiation mode. For now, the driver is in BETA and may be improved.
@All After i have full use of this stuff (and this really, really dramatic improve speed and feel of qemu when you do code with), i am start to curious : can't we have this to be "bootable" ? I mean, if +e bit survives on NTFS, we then can not have any img files , but instead just install on partition (like it can be done with winuae as well too) and so - see system files from windows too (which quite helpfull as well)..
@kas1e Virtfs root works with Linux guest as mentioned in the docs linked before but to boot from it you probably need the kernel to recognise it as a bootable partition and without a partition table that may be difficult. If you can set the root device somehow to boot from that may work. But virtio-scsi should also have similar speed and that should work better as it emulates whole disk with partitions.
But virtio-scsi should also have similar speed and that should work better as it emulates whole disk with partitions.
I may talk bull, but as far as i see virtio-scsi its the same "img" file, just which i can see as real partition in the qemu. But what i want is to have just directory "System:" on windows, in which installed files of os4 can be seen as regular files (just like now in SHARED: with virtio-fs.handler).
ps. to be honest i not fully understand for now difference between having os4.img as it were done before, and scsi.img. Is is give any benefits ? I mean in both ways it's .img file which i need to partition and install on. Or i miss some major point ?
@kas1e No, that's the point. Image file is like a disk on which you have partitions and virtio-9p is like a network share that you mount. When the kernel boots it reads RDB from disks and looks for a boot partition which it can find with an image and virtio-scsi where the virtio-scsi driver is just like a disk driver otherwise everything is like on real machine with disks but what happens with a virio-9p driver? How does it know which share to mount and how does the kernel know it should boot from that when there's no RDB with partitions and a bootable flag anywhere? With Linux the 9p client is in kernel and there are options to tell it to mount and look for the root filesystem on a 9p share. But is there something similar in AmigaOS kernel or could just a virtio-9p driver provide that? A 9p driver may have an otion to tell it to mount a share but how do you tell the AmigaOS kernel that it should boot from that device if it has no RDB?
The difference between an emulated IDE and virtio-scsi is not in the image file, that's the same but emulated IDE goes through IO and interrupts which is slower than virtio that uses shared memory to communicate with QEMU with less emulation overhead.
ps. to be honest i not fully understand for now difference between having os4.img as it were done before, and scsi.img. Is is give any benefits ?
Should make next to no difference with old file systems like SFS as they can't take advantage of drivers supporting NCQ or similar (nearly all SCSI drivers, nvme.device, virtscsi.device, ...) as they are only doing a single device I/O and wait for completion before starting the next device I/O command. Other file systems could be much faster on such devices, but I don't know if NGFS or filesysbox.library based file systems (NTFS-3G and several other FUSE file system ports) use multiple, parallel device I/O commands.
For booting AmigaOS from a 9PFS handler support for the 'e' protection bit isn't enough, additionally at least the 's' protection bit is required. Ideally all 16 AmigaOS protection bits should be supported, as well as the UID and GID numbers. What you could do is using a small image file boot partition and put something like
Set Echo OFF
FailAT 15
Mount SHARED:
IF EXISTS SHARED:
Assign SYS: SHARED:
Assign C: SYS:C
Assign S: SYS:S
... (repeat for all default system assigns)
Execute S:Startup-Sequence
QUIT
ENDIF
at the beginng of the Startup-Sequence. That way most of the OS is loaded from the 9PFS mounted directory.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
