On Thursday, May 23, 2019 at 3:55:24 AM UTC-6, jeanne....@gmail.com wrote:
> Le samedi 9 février 2019 06:26:29 UTC+1, michael...@gmail.com a écrit :
> > On Friday, February 8, 2019 at 8:40:18 AM UTC-7, Henning Schild wrote:
> > > Am Thu, 7 Feb 2019 16:53:41 -0800
> > > schrieb <michael.***@gmail.com>:
> > >
> > > > On Wednesday, February 6, 2019 at 5:59:09 AM UTC-7, Henning Schild
> > > > wrote:
> > > > > Am Tue, 5 Feb 2019 19:25:28 -0800
> > > > > schrieb <michael.***@gmail.com>:
> > > > >
> > > > > > On Friday, February 1, 2019 at 12:32:40 AM UTC-7, J. Kiszka
> > > > > > wrote:
> > > > > > > You likely want
> > > > > > > https://github.com/siemens/linux/commits/jailhouse-enabling/4.14
> > > > > > > or the 4.19-variant that is jailhouse-prepared. That's what
> > > > > > > jailhouse-images is building for you. If you just rebuild the
> > > > > > > kernel that the original image was using, only adding UIO, you
> > > > > > > should be fine with keeping the jailhouse kernel package
> > > > > > > untouched. But the cleanest way is reproducing the image via
> > > > > > > jailhouse-images after adjusting the parameter you want to
> > > > > > > change (CONFIG_UIO, ROOTFS_EXTRA etc.).
> > > > > > >
> > > > > > > Jan
> > > > > > >
> > > > > > > --
> > > > > > > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > > > > > > Corporate Competence Center Embedded Linux
> > > > > >
> > > > > > That worked! I was able to figure out the correct kernel to build
> > > > > > by looking at
> > > > > > jailhouse-images/recipes-kernel/linux/linux-jailhouse.bb from
> > > > > > when I last generated my image at 4.14.73
> > > > > > (https://github.com/siemens/linux/archive/1dd68658b3a8308a160b0786fc4e1e04d8ff5216.tar.gz).
> > > > > > With that, I supplied QEMU with the new UIO-enabled kernel image
> > > > > > and built jailhouse and uio_ivshmem.ko and ran the ivshmem
> > > > > > jailhouse demo.
> > > > > >
> > > > > > However, I'm still not sure how to read in the data from the
> > > > > > ivshmem-demo. Once I insmod uio_ivshmem.ko, shouldn't there be a
> > > > > > device called /dev/uio0 that I can read "Hello From IVSHMEM" from
> > > > > > and write back to? And shouldn't there be an entry
> > > > > > in /sys/class/uio/? I don't see either of these, and I'm not
> > > > > > quite sure how to debug this yet.
> > > > >
> > > > > Yes you should get that. If you do not, my first guess would be that
> > > > > you are not building the jailhouse branch of the guest-code repo.
> > > > > The jailhouse version of the PCI interface is slightly different,
> > > > > so the probing between the two is not compatible.
> > > > Shouldn't I see /dev/uio0 and /sys/class/uio/ once I `insmod` it,
> > > > regardless if it's built against a non-jailhouse-enabled kernel? Or
> > > > will it show up once jailhouse is running?
> > >
> > > I am not actually sure what will happen, so if a /dev/uio0 will pop up
> > > even if probing failed.
> > > Just to clarify, i did not talk about a jailhouse enabled kernel, i
> > > talked about checking out the jailhouse branch of the repo you got the
> > > uio driver from. The one from branch "master" will not work!
> >
> > Thanks! That's just what I needed. I didn't realize that there was a
> > jailhouse branch. I rebuilt it, /dev/uio0 shows up, and the ivshmem-demo is
> > working! uio_read and shmem_test.py (README.jailhouse) both work great.
> >
> > But unfortunately uio_send doesn't. When I run `uio_send /dev/uio0 1 0 0`,
> > it fails to mmap() with an ENODEV/"No such device" error. The mmap man page
> > says "the underlying filesystem of the specified file does not support
> > memory mapping."
> >
> > Do you know why this is? Isn't uio_send just trying to mmap() the PCI
> > config space (the first 256 bytes)?
> >
> > Thanks,
> > -Michael
> >
> > >
> > > Henning
> > >
> > > > When I `make` uio_ivshmem, it shows that it's entering the correct
> > > > kernel source. Is https://github.com/siemens/linux/commit/1dd68658b
> > > > not the correct jailhouse-enabled source to build for 4.14.73?
> > > >
> > > > Does making all the UIO modules be built-in (Y) instead of (M) make
> > > > any difference? I set them to Y because I thought it would make
> > > > things easier.
> > > >
> > > > I may consider upgrading jailhouse images to the latest if I can't
> > > > get things working.
> > > >
> > > > Thanks,
> > > > Michael
> > > > >
> > > > > Henning
> > > > >
> > > > > > The only documentation I can find on this is
> > > > > > https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html.
> > > > > >
> > > > > > Any help is appreciated. Sorry to be a bother. Thanks!
> > > > > > -Michael
> > > > > >
> > > >
>
> Hi Michael,
>
> I am in the same situation as you with the "no such device" during the mmap.
> Were you able to solve your problem? If so, how?
>
> Best regards,
>
> Jeanne
Hello,
Sorry, I wasn't able to fix it 100%, at least for the registers.
I tried mmapping the first page of uio0 for the registers like this:
static const char *UIO_FILE = "/dev/uio0";
static const char *RES_0_FILE = "/sys/class/uio/uio0/device/resource0";
// Get the page size of the system (usually 4096)
PAGESIZE = sysconf(_SC_PAGESIZE);
// Open the files
uio0_fd = open(UIO_FILE, O_RDWR);
res0_fd = open(RES_0_FILE, O_RDWR);
if (uio0_fd == -1) {
printf("ERR %d: %s\n", errno, strerror(errno));
exit(-1);
}
if (res0_fd == -1) {
printf("ERR %d: %s\n", errno, strerror(errno));
exit(-1);
}
printf("Trying to mmap registers from %s\n", UIO_FILE);
registers = (unsigned int *) mmap(NULL, PAGESIZE, PROT_READ|PROT_WRITE,
MAP_SHARED, uio0_fd, PAGESIZE*0);
if (registers == (void *) -1) {
printf("registers mmap failed for %s (%p)\n", UIO_FILE, registers);
printf("ERR %d: %s\n", errno, strerror(errno));
// Try again, but this time use the resource 0 version
// This call succeeds in QEMU Jailhouse Image, but not on Inspiron
printf("Trying to mmap registers from %s\n", RES_0_FILE);
registers = (unsigned int *) mmap(NULL, PAGESIZE, PROT_READ|PROT_WRITE,
MAP_SHARED, res0_fd, PAGESIZE*0);
if (registers == (void *) -1) {
printf("registers mmap failed for %s (%p)\n", RES_0_FILE,
registers);
printf("ERR %d: %s\n", errno, strerror(errno));
exit(-1);
}
}
Mapping /dev/uio0 worked in the QEMU image built by Jailhouse, but not on my
x86-64 Dell Inspiron laptop.
I tried to get around this by mmapping /sys/class/uio/uio0/device/resource0
instead, which mmap()s successfully on the Inspiron, but it didn't seem to
read/write to the registers at all. So I don't think that will work. But maybe
you'll have better luck.
Of note, I also wasn't able to listen to interrupts in Inspiron by reading
/dev/uio0, but that could be due to a bad configuration.
In both QEMU and on the Inspiron, though, I was still able to mmap the shared
memory page like this, which was the most important thing for me:
// Get the shared memory at +PAGESIZE offset of /dev/uio0
shmem = (unsigned int *) mmap(NULL, PAGESIZE, PROT_READ|PROT_WRITE,
MAP_SHARED, uio0_fd, PAGESIZE*1);
if (shmem == (void *) -1) {
printf("shmem mmap failed (%p)\n", shmem);
printf("MGH: ERR %d: %s\n", errno, strerror(errno));
exit(-1);
}
printf("shmem mmap succeeded! Address:%p\n", shmem);
Since I was able to at least get this working, I didn't care too much about
accessing the registers or getting interrupts to work.
I adapted this last snippet to Python 3 (inspired by shmem_test.py):
import mmap
PAGE_SIZE = 4096
device_file = '/dev/uio0'
f = open(device_file, 'r+b')
shmem = mmap.mmap(f.fileno(), PAGE_SIZE, offset=PAGE_SIZE)
print("Shmem content (first 30 bytes): '%s'" % shmem.read(30))
print("This also works: '%s'" % shmem[0:30].hex())
str_bytes = bytearray("Hello from root", 'utf-8')
str_bytes_len = len(str_bytes)
shmem[0:str_bytes_len] = str_bytes
This is a lot more convenient for rapid prototyping (This is condensed from my
actual script, so hopefully it doesn't err. But it should be mostly correct).
Hope that helps,
-Michael
--
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 jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/945f6563-0e61-4d00-8ec0-415b27df174a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
