search for: iowrite

https://bugs.freedesktop.org/show_bug.cgi?id=92560 Bug ID: 92560 Summary: [GK208] iowrite goes out of bounds on channel close Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freede...

...ocations. Yes. In more detail, instruction words directly control the data transports inside the processor, and I/O is handled by transporting data into a special function unit. > In that case, you would not > use a "system call" intrinsic; Correct. > you would use an ioread/iowrite intrinsic > (these are similar to load/store and are briefly documented in the > LLVA-OS paper). Which I should probably read, it seems. If you're doing memory mapped I/O, you could probably > use LLVM volatile load/store instructions and not have to add any > intrinsics. We c...

...miroarchitecture a particular piece of data should go. Directing it to a specific functional unit makes it do I/O. Right? > >> In that case, you would not >> use a "system call" intrinsic; >> > > Correct. > > >> you would use an ioread/iowrite intrinsic >> (these are similar to load/store and are briefly documented in the >> LLVA-OS paper). >> > > Which I should probably read, it seems. > The LLVA-OS paper contains descriptions of intrinsics that we would add to LLVM to support an operating system. In...

...ally stopping all of them to take > > pointer to const. > > Shouldn't all of them take const volatile __iomem pointers? > It seems the "volatile" is missing from all but the implementations in > include/asm-generic/io.h. As my "volatile" comment applies to iowrite*(), too, probably that should be done in a separate patch. Hence with patches 1-5 squashed, and for patches 11-13: Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32...

to read address before selecting the correct vq. At that point, I've added simple prints to the driver. Initially it looked as follows: iowrite16(index, &vp_dev->common->queue_select); switch (ioread64(&vp_dev->common->queue_address)) { [...] }; So I added prints before the iowrite16() and after the ioread64(), and saw that while the driver prints were ordered, the device ones weren't: [ 1.264052] before...

to read address before selecting the correct vq. At that point, I've added simple prints to the driver. Initially it looked as follows: iowrite16(index, &vp_dev->common->queue_select); switch (ioread64(&vp_dev->common->queue_address)) { [...] }; So I added prints before the iowrite16() and after the ioread64(), and saw that while the driver prints were ordered, the device ones weren't: [ 1.264052] before...

Currently virtio-pci is specified so that configuration of the device is done through a PCI IO space (via BAR 0 of the virtual PCI device). However, Linux guests happen to use ioread/iowrite/iomap primitives for access, and these work uniformly across memory/io BARs. While PCI IO accesses are faster than MMIO on x86 kvm, MMIO might be helpful on other systems which don't implement PIO or where PIO is slower than MMIO. Add a property to make it possible to tweak the BAR type. Sig...

Currently virtio-pci is specified so that configuration of the device is done through a PCI IO space (via BAR 0 of the virtual PCI device). However, Linux guests happen to use ioread/iowrite/iomap primitives for access, and these work uniformly across memory/io BARs. While PCI IO accesses are faster than MMIO on x86 kvm, MMIO might be helpful on other systems which don't implement PIO or where PIO is slower than MMIO. Add a property to make it possible to tweak the BAR type. Sig...

...d32, const) If these would become "const volatile", there would no longer be a need for the last parameter of the REMAP1() macro. > REMAP1(u8, readb, const volatile) > REMAP1(u16, readw, const volatile) > REMAP1(u32, readl, const volatile) Same for REMAP2() macro below, for iowrite*(). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or s...

...ce that owns the BAR * @bar: BAR number - * @maxlen: length of the memory to map + * @offset: map memory at the given offset in BAR + * @maxlen: max length of the memory to map * * Using this function you will get a __iomem address to your device BAR. * You can access it using ioread*() and iowrite*(). These functions hide @@ -21,16 +22,21 @@ * you expect from them in the correct way. * * @maxlen specifies the maximum length to map. If you want to get access to - * the complete BAR without checking for its length first, pass %0 here. + * the complete BAR from offset to the end, pass %0...

...ce that owns the BAR * @bar: BAR number - * @maxlen: length of the memory to map + * @offset: map memory at the given offset in BAR + * @maxlen: max length of the memory to map * * Using this function you will get a __iomem address to your device BAR. * You can access it using ioread*() and iowrite*(). These functions hide @@ -21,16 +22,21 @@ * you expect from them in the correct way. * * @maxlen specifies the maximum length to map. If you want to get access to - * the complete BAR without checking for its length first, pass %0 here. + * the complete BAR from offset to the end, pass %0...

...@maxlen: length of the memory to map + * @offset: map memory at the given offset in BAR + * @minlen: min length of the memory to map + * @maxlen: max length of the memory to map * * Using this function you will get a __iomem address to your device BAR. * You can access it using ioread*() and iowrite*(). These functions hide * the details if this is a MMIO or PIO address space and will just do what * you expect from them in the correct way. * + * @minlen specifies the minimum length to map. We check that BAR is + * large enough. * @maxlen specifies the maximum length to map. If you want...

...@maxlen: length of the memory to map + * @offset: map memory at the given offset in BAR + * @minlen: min length of the memory to map + * @maxlen: max length of the memory to map * * Using this function you will get a __iomem address to your device BAR. * You can access it using ioread*() and iowrite*(). These functions hide * the details if this is a MMIO or PIO address space and will just do what * you expect from them in the correct way. * + * @minlen specifies the minimum length to map. We check that BAR is + * large enough. * @maxlen specifies the maximum length to map. If you want...

...er to const. >>> >>> Shouldn't all of them take const volatile __iomem pointers? >>> It seems the "volatile" is missing from all but the implementations in >>> include/asm-generic/io.h. >> >> As my "volatile" comment applies to iowrite*(), too, probably that should be >> done in a separate patch. >> >> Hence with patches 1-5 squashed, and for patches 11-13: >> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be> > > I'll add to this one also changes to ioreadX_rep() and add another...

...and this right: First, it sounds like you're programming on the bare processor, so your I/O instructions are either special processor instructions or volatile loads/stores to special memory locations. In that case, you would not use a "system call" intrinsic; you would use an ioread/iowrite intrinsic (these are similar to load/store and are briefly documented in the LLVA-OS paper). If you're doing memory mapped I/O, you could probably use LLVM volatile load/store instructions and not have to add any intrinsics. Second, you could implement these "intrinsics" as either e...

This is in response to Reid's and John's comments about intrinsics. The setting of the work is a project on reconfigurable processors using the Transport Triggered Architecture (TTA) <http://en.wikipedia.org/wiki/Transport_triggered_architecture>. For the compiler this means that the target architecture is not fixed, but rather an instance of a processor template. Different

...> > > pointer to const. > > > > Shouldn't all of them take const volatile __iomem pointers? > > It seems the "volatile" is missing from all but the implementations in > > include/asm-generic/io.h. > > As my "volatile" comment applies to iowrite*(), too, probably that should be > done in a separate patch. > > Hence with patches 1-5 squashed, and for patches 11-13: > Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be> I'll add to this one also changes to ioreadX_rep() and add another patch for volatile for re...

...> >>> Shouldn't all of them take const volatile __iomem pointers? > >>> It seems the "volatile" is missing from all but the implementations in > >>> include/asm-generic/io.h. > >> > >> As my "volatile" comment applies to iowrite*(), too, probably that should be > >> done in a separate patch. > >> > >> Hence with patches 1-5 squashed, and for patches 11-13: > >> Reviewed-by: Geert Uytterhoeven <geert+renesas at glider.be> > > > > I'll add to this one also changes to...

..."const volatile", there would no longer be a need > for the last parameter of the REMAP1() macro. > > > REMAP1(u8, readb, const volatile) > > REMAP1(u16, readw, const volatile) > > REMAP1(u32, readl, const volatile) > > Same for REMAP2() macro below, for iowrite*(). Good point, thanks! Best regards, Krzysztof

...0 and non S_ISREG" mv /tmp/predicted /tmp/other ln -s /some/old/target /tmp/predicted Is there some reason (such as standards or a situation I've overlooked) why they should do this and not say noclobber => O_EXCL, end of story ? exec.c from pdksh-5.2.12 1293 case IOWRITE: 1294 flags = O_WRONLY | O_CREAT | O_TRUNC; 1295 if (Flag(FNOCLOBBER) && !(iop->flag & IOCLOB) 1296 && (stat(cp, &statb) < 0 || S_ISREG(statb.st_mode))) 1297 flags |= O_EXCL; 1298 break; execute_cmd.c from bash-1.14.7 2834 stat_result = stat (...