Am Mon, 18 Dec 2017 07:41:34 -0800 schrieb Luca Cuomo <[email protected]>:
> Il giorno lunedì 18 dicembre 2017 16:22:37 UTC+1, Henning Schild ha > scritto: > > Am Mon, 18 Dec 2017 05:58:11 -0800 > > schrieb Luca Cuomo <[email protected]>: > > > > > > > Hi, > > > > > > > > > > I can now confirm that the patch 87fbf1f works and interrupts > > > > > are received correctly, /dev/uiox is accessible and works as > > > > > expected. Without it, I got a: "FATAL: forbidden access > > > > > (exception class 0x24)" but I don't remember if this was > > > > > triggered by Jailhouse or Linux. > > > > > > > > Thanks, applied to "jailhouse" and removed "jailhouse-next". > > > > > > > > Henning > > > > > > > > > Best Regards, > > > > > Constantin > > > > > > > > > > > Hi all, > > > > > > i've got a strange situation. I'm using the latest jailhouse > > > branch on x86 with a linux root cell and a Bare Metal cell > > > connected via 2 pci device (bdf e.00 and f.00). > > > > > > Two Ivshmem device are correctly mapped to /dev/uio0 > > > and /dev/uio1. But if on /dev/uio0 i can correctly map registers > > > ( offset 0, size 0x1000) and shmem (offset 0x1000, size 0x1000), > > > for /dev/uio1 the first mapping fails with the ENODEV errno set > > > (shmem mapping is done correctly). Parameters of mapping are the > > > same for uio0 and uio1. > > > > > > Here i list a dmesg snippet of the root cell kernel: > > > > > > [ 302.092280] pci 0000:00:0e.0: [1af4:1110] type 00 class > > > 0xff0000 [ 302.092622] pci 0000:00:0e.0: reg 0x10: [mem > > > 0x00000000-0x000000ff 64bit] [ 302.092776] > > > hpet_rtc_timer_reinit: 39 callbacks suppressed [ 302.092777] > > > hpet1: lost 62 rtc interrupts [ 302.093025] pci 0000:00:0e.0: > > > reg 0x20: [mem 0x00000000-0x0000001f 64bit] [ 302.093634] pci > > > 0000:00:0e.0: BAR 0: assigned [mem 0xc0000000-0xc00000ff 64bit] > > > [ 302.093765] pci 0000:00:0e.0: BAR 4: assigned [mem > > > 0xc0000100-0xc000011f 64bit] [ 302.093982] virtio-pci > > > 0000:00:0e.0: enabling device (0000 -> 0002) [ 302.094169] > > > uio_ivshmem 0000:00:0e.0: using jailhouse mode [ 302.094625] > > > uio_ivshmem 0000:00:0e.0: MSI-X enabled [ 302.094918] pci > > > 0000:00:0f.0: [1af4:1110] type 00 class 0xff0000 [ 302.095259] > > > pci 0000:00:0f.0: reg 0x10: [mem 0x00000000-0x000000ff 64bit] > > > [ 302.095725] pci 0000:00:0f.0: reg 0x20: [mem > > > 0x00000000-0x0000001f 64bit] [ 302.096468] pci 0000:00:0f.0: BAR > > > 0: assigned [mem 0xc0000200-0xc00002ff 64bit] [ 302.096667] pci > > > 0000:00:0f.0: BAR 4: assigned [mem 0xc0000120-0xc000013f 64bit] > > > [ 302.096962] virtio-pci 0000:00:0f.0: enabling device (0000 -> > > > 0002) [ 302.097139] uio_ivshmem 0000:00:0f.0: using jailhouse > > > mode [ 302.097568] uio_ivshmem 0000:00:0f.0: MSI-X enabled > > > > I do not remember whether i tested the uio-driver with multiple > > devices, i can not rule out a hidden bug in there. The output looks > > pretty much the same for both instances and does not seem too > > useful. > > Even the /sys/class/uio/uiox ... directories seem to be ok. > > > What would be interesting is which call fails and where it fails in > > the kernel? Could you "unbind" the two devices from the driver and > > "bind" them the other way around, does that make the "second" work > > and the "first" fail? > > This could be a good idea but how do you suggest to unbind them? # echo 0000:00:0f.0 > /sys/bus/pci/drivers/uio_ivshmem/unbind # echo 0000:00:0e.0 > /sys/bus/pci/drivers/uio_ivshmem/unbind # echo 0000:00:0f.0 > /sys/bus/pci/drivers/uio_ivshmem/bind Now 0f should be your uio0. > > What test-code are you using, if anyone wanted to reproduce the > > setup for further assistance. > > The same result using both the uio_send test which is in the repo and > a self made test which basically does: > > int firstFd = open(/dev/uio0, O_RDWR) //ok > mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, firstFd, > 0) //regs ok mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, > firstFd, 4096) //shmem ok > > int secondFd = open(/dev/uio1, O_RDWR) //ok > mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, secondFd, > 0) //regs FAIL mmap( NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, > secondFd, 4096) //shmem ok Ok, let us see where this is coming from with ftrace. Could you try something like this, best on an otherwise idle system: trace-cmd record -p function -l '*mmap*' yourtest trace-cmd report Maybe check out the documentation of ftrace to get closer to the root cause of the error. The mmap itself is not even implemented in the driver, i am guessing a parameter like size or location might be wrong. But if you can mmap it from /dev/mem i might also be an alignment issue. We basically have to trace that mmap-call to the condition in the kernel returning the error. > The way i can overcome the problem for the second device is reading > the address from /sys/class/uio/uio1/maps/map0/addr and then mmapping > from /dev/mem with the proper offset > (/sys/class/uio/uio1/maps/map0/offset) Well from a security point of view, i would not suggest that. Rather have your uios in a group via udev ... For now a good workaround but i would like to understand and fix it, if it is something in the uio-driver. Henning > > Henning > > > > > What i'm doing wrong? I do exactly the same things on /dev/uio0 > > > and /dev/uio1 > > Thanks, > > --Luca > > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
