<Pellescours>the fact that I compile ata with sata support mean that I can’t compile rumpdisk with only libata and piixide (a method is missing). I don’t think it’s an issue for hurd but if we want the patches to be upstreamed to netbsd, this can be a problem <damo22>netbsd doesnt have ide/sata disk drivers in rump <damo22>anything we provide is already better than nothing <Pellescours>piixide is really slow really It look like I didn’t started qemu with kvm, but only for disk interraction <Pellescours>it’s not all operations but git operations in rumpkernel, like rebase are so slow. I feel it faster with linux driver, I don’t know if it’s an impression or real <Pellescours>I send the patch to the bug-hurd, damo22 can you test on real hardware to ensure it works. <Pellescours>for the DMA problem with piixide, it’s still there, the error message is "piixide0:1: unable to allocate table DMA map for drive 0, error=1" <Pellescours>ok, this error appear because rumpcomp_pci_dmamem_map is not able to handle map of more than 1 seg <damo22>Pellescours: i think flags 0x0000 means no DMA allowed with the wd <damo22>if you remove the flags it should work <Pellescours>It tried to dma but don’t work because the rumpcomp_pci_dmamem_map implementation is not able to handle mapping of multiple segments <damo22>you could try the suggestion from there <damo22>ie, call mremap() using the parameters passed in <damo22>so the mapping gets enlarged to totlen <damo22>or some kind of vmallocate_contiguous? <damo22>why cant the dmalloc be big enough <damo22>why does rump want to extend it? <Pellescours>I don’t know, I’m recompiling rumpkernel to have the informations <damo22>what does mremap do? if it retains the base physical address and just makes the mapping bigger, that is sufficient <damo22>see how it implements it via the rump call <damo22>it may be that its already allocated and we can release the restriction, im not sure <Pellescours>It’s a kalloc a foreach to initalize the struct and the rumpcomp_pci_map call <damo22>or does it make nseg x rumpcomp_pci_map calls <damo22>yea bus_dmamem_alloc is currently a hack, and theres no rump hypercall that can give it scatter-gather memory <damo22>i was talking to someone about this in netbsd <damo22>it needs to be fixed but no one is working on it <damo22>i think its an array of mappings that are physically contiguous <damo22>so we could allocate it in one block using vmallocate_contiguous and break it up into chunks perhaps <Pellescours>our rumpcomp_pci_dmalloc already do a vmallocate_contiguous, so the bus_dmamem_alloc already does it for us (split into chunks) <damo22>yes but it only currently supports nseg =1 <damo22>i think its ignoring boundary and nsegs <damo22>since that is not passed into the rump call <damo22>maybe we can just allocate it in one chunk and ignore multiple segments? <damo22>the problem is, bus_dmamem_map asks for multiple segments <damo22>i think the alloc is allocating it in one chunk but the map is asking for the same region in smaller chunks <Pellescours>can we just construct a map by just slicing the buffer and returning it? Or will this cause issues due to vmap <-> pmap correspondance? <damo22>i think the underlying physical memory is contiguous, so the vm address should also be? <damo22>because we use vmallocate_contiguous <damo22>i think slicing the buffer would work <Pellescours>Because we allocated contiguous memory containing all the asked pages, I think we can ignore nseg and always return the same stuff. It’s possible because we know that we allocated continuously, otherwise there is the pmap_enter to generate a contiguous buffer of discontinuous pages <damo22>ohh but the "boundary" is a physical address that it wants the mapping to be at? <damo22>im not sure what boundary is for <Pellescours>If I understood the code correctly, the map step should be a no-op (what is it currently). The map is useful only when the memory returned by alloc is not virtual. <Pellescours>But in our case, we are in userland so we always have a virtual memory returned by alloc <Pellescours>I don’t understand now it’s the vm_allocate_contiguous that fails (so a regression from before) <damo22>or do i need to call __atomic_add_fetch(refcnt, 1, __ATOMIC_SEQ_CST); <Pellescours>damo22: actually it was always the alloc that was failing. I’m trying to get the align and size, but I fear it’s due to the limitation of vm_allocate_contiguous that makes the allocation failing <damo22>see if you can get the params sent to the dmalloc in rump <Pellescours>damo22: dma_table_size: 136 and dma_table_align: 65536 <Pellescours>the align is greater than page size so allocation fails <damo22>int interrupt_demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp) <--- how do i expose this function that needs a struct irq passed in, but i cant change the function prototype?? <Pellescours>damo22: for the vm_allocate_contiguous, can I transform the "if (palign == 0)" into a "if (palign % PAGE_SIZE == 0)"? That would fix the alloc for the dma <Pellescours>with that modification DMA works and it’s super fast <Pellescours>gnumach with APIC is still buggy, I have a lot of "lost interrupt", and at some point the machine "hang", the console cursor is still blinking but not keyboard input is accepted, even in ssh, and if it was doing something (like booting) nothing happen ***foggy68 is now known as foggy67