<youpi>it seems to be going quite fine <damo22>which package needed to be fixed? <youpi>see the commit in the hurd tree <youpi>but it'd rather to be fixed in rump <youpi>it's really not normal that it doesn't check physical pages for each page <youpi>I wouldn't call that a fix ): <youpi>also there's still that /proc/5/stat issue <damo22>i ran fdisk successfully and e2fsck <youpi>yes, now fdisk/e2fsck work fine <youpi>now that unaligned and >page accesses are fixed <youpi>yes, it's all bootstrap processes which have the issue <youpi>we didn't have such issue before <youpi>so we'd see ext2fs in ps etc. <damo22>rumpdisk.static is still using a lot of ram <damo22> 731 root 18 -2 408772 276984 0 S 0.0 13.2 0:29.28 rumpdisk.static <damo22>root@zamhurd:~# cat /etc/mtab |grep wd <damo22>part:2:device:wd0 / ext2fs writable,relatime,no-inherit-dir-group,store-type=typed 0 0 <damo22>i dont think its related to "sudo" because when i use the login tty and log in directly as root, i dont get a shell without ctrl-c twice <damo22>youpi: so what is actually the behaviour in rump that you dispute? the memory in pread is assumed to be contiguous? <youpi>damo22: yes, "alsmot" contiguous" <youpi>it seems to be assuming contiguous by pieces of 4MB <youpi>(the length of a dma piece, apparently) <youpi>and thus having to make multiple pread calls <youpi>it would be possible to use preadv, but it's really odd that rump assumes such contiguity <damo22>isnt a dma buffer contiguous by design? <damo22>ie, you write a continuous piece of memory in one go <damo22>and the boundaries of the buffer correspond necessarily to a particular chunk of physical ram <kilobug>damo22: yes, the DMA controller access memory directly via physical address IIRC, so it needs to be a continuous chunk of physical memory that can't be moved around <damo22>if gnumach is allocating dma buffers by choosing random pages between 0 and DMA32 offset, of course it wont be contiguous <youpi>damo22: I'm not saying the dma shouldn't be contiguous <kilobug>damo22: if you do allocate them in non-continuous chunk, you would have the OS to reprogram the DMA transfert when a chunk is over and the next one needs to be processed (typically the device will trigger an IRQ when it reaches the end of current chunk) <youpi>what I'm saying is the rump doesn't actually check that it's contiguous <youpi>to split the transfer into several dmas <damo22>is that the driver's job or the OS's job? <damo22>does the OS always know the size of a DMA transfer? <kilobug>damo22: I said "OS" as a large concept, including the drivers; it's usually more of the driver's job, but the OS can provides mechanism/primitives to help with it <damo22>yea, youpi implemented it in hurd side <damo22>maybe we can write a helper function around rump_sys_pread/pwrite? <damo22>currently it seems every access is being split into pages, which makes it easier because then you dont even care if it comes out of a DMA area or not, the memory would still be mapped with gnumach per page, but it doesnt allow large accesses to use more than a page at a time <damo22>the virtual addresses of each page in a contiguous physical allocation are not necessarily contiguous right? <damo22>i dont know enough about the memory allocator ***Guest2562 is now known as roptat
<curiosa>Hurd could provide a similar thing, considering that with iommu support user-space dma transfer are currently safe <curiosa>luckyluke I don't know and I wouldn't mind <curiosa>what I know is that it's used in virtualization since it is faster then software virtualization <damo22>(23:35:08) Riastradh: damo22: rump_sys_pread itself doesn't know or assume anything about DMA <damo22>(23:40:13) Riastradh: damo22: If the pread is applied to a character device, which is backed by a block device driver like wd(4), then a buffer is allocated in kva for the underlying DMA transfer using vmapbuf, which on rump either mallocs a bounce buffer or leaves the buffer as is (because there's on separate user virtual address space and kernel virtual address space in rump). <damo22>(23:41:47) Riastradh: damo22: So wd(4) will pass this buffer's virtual address down to ahcisata to initiate a DMA transfer, and ahcisata will probably load a DMA map with bus_dmamap_load which maps a [vaddr, vaddr + len) kva buffer into a series of [baddr0, baddr0 + len0), [baddr1, baddr1 + len1), ..., bus address segments. <damo22>(23:42:45) Riastradh: which on rump, is probably the identity map, because the underlying host's userland PCI interface just works on user virtual addresses for DMA transfers. <damo22>(23:45:31) Riastradh: damo22: So if you do rump_sys_pread(fd, buf, len) where buf is the virtual address of some buffer you allocated with malloc, it looks like it'll be either the same address passed down to the userland PCI interface, or another one allocated by rump_hypermalloc. <Pellescours>I still have the timeout issue when I poweroff my VM using rump <damo22>Pellescours: what timeout issue? <Pellescours>wd0d: device timeout reading fsbn 8521576 of 8521576-8521583 (wd0 bn 8521576; cn 8453 tn 15 sn 7), xfer f90, retry 0