Anyone having experience writing a AOS4 driver for a pci device? I'm trying to write a virtio-... device driver. Currently palying around with block device. So I'm setting up a simple test to write data. It seems from the qemu monitor everything is fine. But I'm struggling with kicking of the write request to the device. From the documentation, is should be quiet simple, just write a value to a specific address in the BAR region. I have that address, I know the value to write. But writing to that address, nothing happens.
Is there a trick form the AmigaOS side, and is there a way to debug/monitor that from the qemu side.
@MigthyMax As for tracing from QEMU side look at qemu/hw/virtio/trace-events for trace points that cen be enabled. You can either add -trace enable="glob pattern" (can use multiple -trace options to enable different traces) or from the QEMU monitor. Also check info pci or info qtree and check that the BARs of the device are enabled and mapped or you can also use -trace enable="pci*" to check access to PCI regs. Adding -d unimp,guest_errors may also show access to wrong memory addresses but some of those are because of not emulated hardware so may not be an error.
Now there are at least 3 people working on virtio drivers independently. Isn't it time to collaborate on a virtio.library to avoid duplicated work? Is there anybody who wants to publish their virtio access routines under an open source license to make them a standard way to access virtio devices on AmigaOS that everybody can use?
The BAR mapping looks good, as long I understand everything.
I test all the options suggested. During the run of my test, no output was giving. Which makes me wonder because using "-trace enable="pci*"" only gives output during startup of the OS. But if I start my test, and it read in the pci configuration space. No additional message were written by this option.
Yeah, we should work together, but except Hans who is the third person? Any my code is just at the moment a hack done, to see how everything works.
balaton wrote:@MigthyMax Now there are at least 3 people working on virtio drivers independently. Isn't it time to collaborate on a virtio.library to avoid duplicated work? Is there anybody who wants to publish their virtio access routines under an open source license to make them a standard way to access virtio devices on AmigaOS that everybody can use?
@MigthyMax If you don't see access with -trace enable="pci*" when reading writing config space then it does not reach the emulated device. The pci_* trace points only show config space access, accesses to BAR aread may need enabling virtio trace points but qemu/hw/virtio/virtio-pci.c does not seem to have any. You can try to add printfs or traces to *_read/*_write functions in that file to see if they are called. Are you using the right address where it's mapped and is the correct enable bits set in the BAR? See Memory Space and IO Space bits in https://wiki.osdev.org/PCI#Command_Register (the Bus Master bit may also be needed if the device wants to write to memory with DMA). If the firmware does not know the device then it may only program the BARs but not actually enable the device so unless you enable it no access will succeed.
If you're the same person working in a virtio-net driver (you've mentioned virtio-blk above) then there may be only 2 people.
Please try contacting A-EON about using the virtio.library
Mean no open source, another sites to register to download it, another ownership who want to dictate when and how to use it. Maybe can be ok with closed source stuff, but with QEMU having developers to rely on closed source library, IMHO no way to go.
You may know the situation already with all those AEON's classes, which you can't just download from os4depot (you need to register on some sites for), as well as of course they not open sourced, which in end leads to their usage only mostly inside of the Enhancer itself.
If ppls will be in needs to contact to the Mattew (yeah, that Mattew who answer years for simple questions), to get access to the closed source library, to sign some document or register on some site, that IMHO just crazy. Especially when it comes to the things like opensourced emulator (all the work for which done for free mostly).
I am fully up to have video driver for QEMU being closed source and for sale to cover the cost of your work, but anyone else who work for free, IMHO should not step in that mess. I'm seeing all over the places how ppls can't get simple things for aeon tracker be fixed for YEAR! Or how their sites can't be fixed to properly handle SSL things.. IMHO, if one wants to save their nervous, they shouldn't try to do any work based on the AEON's closed source stuff. It leads to the same (if not worse) issues as it was with Hyperion and whole contacting with Mattew and getting answer from him or any action, it's like talking to the black hole.
Mean no open source, another sites to register to download it, another ownership who want to dictate when and how to use it. Maybe can be ok with closed source stuff, but with QEMU having developers to rely on closed source library, IMHO no way to go.
This has zero effect on Qemu developers. It only matters to those writing drivers for AmigaOS.
Incidentally, Virtio isn't only for Qemu. It's also supported by other Virtual Machines (VMs).
Quote:
If ppls will be in needs to contact to the Mattew (yeah, that Mattew who answer years for simple questions), to get access to the closed source library, to sign some document or register on some site, that IMHO just crazy.
You're assuming that people will have to sign an NDA to get access. I don't remember them doing that with their classes.
The reason that I'm encouraging people to contact A-EON, is so that A-EON is aware that people want access to the library. Hopefully that'll nudge them to take action sooner rather than later. I've already encouraged them to open up access to the library.
You're assuming that people will have to sign an NDA to get access. I don't remember them doing that with their classes.
Not exactly NDA, but one need to wait when Mattew answer (can never happen). Or they will be in needs to register on some site (as it done with classes).
Quote:
The reason that I'm encouraging people to contact A-EON, is so that A-EON is aware that people want access to the library. Hopefully that'll nudge them to take action sooner rather than later. I've already encouraged them to open up access to the library.
If they simply upload it on os4depot for everyone's usage: then that will be very good and correct way : everyone who will be in needs can use it. All good.
But it wasn't like this with classes, and surely will not happen with this library too (i hope to be wrong). Those developers who will be in interest to use this library, will be forced to wait when Mattew will find a time to answer with putting a restriction usage on top of it :)
Do you think they can upload it to os4depot in the end for everyone's usage ? I didn't believe in, but hope to be wrong :)
Host features:
VIRTIO_RING_F_EVENT_IDX: Used & avail. event fields enabled,
VIRTIO_RING_F_INDIRECT_DESC: Indirect descriptors supported,
VIRTIO_F_RING_RESET: Driver can reset a queue individually,
VIRTIO_F_VERSION_1: Device compliant for v1 spec (legacy),
VIRTIO_F_ANY_LAYOUT: Device accepts arbitrary desc. layouts,
VIRTIO_F_NOTIFY_ON_EMPTY: Notify when device runs out of avail. descs. on VQ
VHOST_USER_F_PROTOCOL_FEATURES: Vhost-user protocol features negotiation supported,
VIRTIO_BLK_F_CONFIG_WCE: Cache writeback and writethrough modes supported,
VIRTIO_BLK_F_FLUSH: Flush command supported,
VIRTIO_BLK_F_WRITE_ZEROES: Write zeroes command supported,
VIRTIO_BLK_F_DISCARD: Discard command supported,
VIRTIO_BLK_F_TOPOLOGY: Topology information available,
VIRTIO_BLK_F_BLK_SIZE: Block size of disk available,
VIRTIO_BLK_F_GEOMETRY: Legacy geometry available,
VIRTIO_BLK_F_SEG_MAX: Max segments in a request is seg_max
Backend features:
And I even setup a request in the queue:
(qemu) info virtio-queue-element /machine/peripheral-anon/device[3]/virtio-backend 0 0
Desc next is 768
/machine/peripheral-anon/device[3]/virtio-backend:
device_name: virtio-blk
index: 0
desc:
descs:
addr 0x471ad70 len 1 (write, next),
addr 0x4709ca0 len 7 (next),
addr 0x471ad60 len 16 (next)
avail:
flags: 0
idx: 0
ring: 0
used:
flags: 0
idx: 256
(qemu)
The "only" thing is, I cannot signal the device like described in chapter 4.1.4.4.1. I calculate the address, but writing any kind of value into that address location, results in nothing. No error message from qemu, no processing of the virtqueue entries. And yes the PCI command register has bit 2 set.
So that's is where I need help, or least some kind of debug output telling my what qemu thinks is wrong.
And yes I will contact Matthew. But I already had my code, a long time before the virtio.library was made public known.
If they simply upload it on os4depot for everyone's usage: then that will be very good and correct way : everyone who will be in needs can use it. All good.
But it wasn't like this with classes, and surely will not happen with this library too (i hope to be wrong). Those developers who will be in interest to use this library, will be forced to wait when Mattew will find a time to answer with putting a restriction usage on top of it :)
Do you think they can upload it to os4depot in the end for everyone's usage ? I didn't believe in, but hope to be wrong :)
You have made me curious. As I understood it. E.g. an ordinary person who would like to do something with VAAPI for AOS4 has to ask @ for an API, register somewhere, sign something ? VAAPI is only for A-EON products ?
If they simply upload it on os4depot for everyone's usage: then that will be very good and correct way : everyone who will be in needs can use it. All good.
But it wasn't like this with classes, and surely will not happen with this library too (i hope to be wrong). Those developers who will be in interest to use this library, will be forced to wait when Mattew will find a time to answer with putting a restriction usage on top of it :)
Do you think they can upload it to os4depot in the end for everyone's usage ? I didn't believe in, but hope to be wrong :)
You have made me curious. As I understood it. E.g. an ordinary person who would like to do something with VAAPI for AOS4 has to ask @ for an API, register somewhere, sign something ? VAAPI is only for A-EON products ?
Im assuming they are talking about the Enhancer Software Core 2 pack (link here) as that requires an Amisphere login to download the pack for free.
My own opinion is it doesnt matter what website you get it from, as its still free and Matthew will still have the same limited time to do things. There are much better things to spend time on.
@MigthyMax It's hard to know what you're doing without a lot of details or seeing the code so it's hard to help. I don't know what's happening but if you think writes don't reach QEMU you could add additional logging in the virtio-pci as I said before to see what values reach there.
Other than that, maybe check if addresses written in the queue are correct. I'm not sure but I think virtio devices need physical addresses as they don't know about the CPU virtual addresses so unless you have a one to one mapping you may need to translate addresses to physical memory locations that you tell the device to operate on.
Also you can try -trace enable="virtqueue*" to see changes to queue. See other trace entries in qemu/hw/virtio/trace-events.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
