Re: [Xen-devel] clean up and modularize arch dma_mapping interface
On Thu, Jun 08, 2017 at 03:25:25PM +0200, Christoph Hellwig wrote: > Hi all, > > for a while we have a generic implementation of the dma mapping routines > that call into per-arch or per-device operations. But right now there > still are various bits in the interfaces where don't clearly operate > on these ops. This series tries to clean up a lot of those (but not all > yet, but the series is big enough). It gets rid of the DMA_ERROR_CODE > way of signaling failures of the mapping routines from the > implementations to the generic code (and cleans up various drivers that > were incorrectly using it), and gets rid of the ->set_dma_mask routine > in favor of relying on the ->dma_capable method that can be used in > the same way, but which requires less code duplication. > > Btw, we don't seem to have a tree every-growing amount of common dma > mapping code, and given that I have a fair amount of all over the tree > work in that area in my plate I'd like to start one. Any good reason > to that? Anyone willing to volunteer as co maintainer? > > The whole series is also available in git: > > git://git.infradead.org/users/hch/misc.git dma-map Ack for the 2 drm patches, but I can also pick them up through drm-misc if you prefer that (but then it'll be 4.14). -Daniel > > Gitweb: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-map > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seems to be a missing adaption similar to that done in
> commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> to i915_gem_object_get_pages_internal().
>
> So limit the maximum page order to be used according to the maximum
> swiotlb segment size instead to the complete swiotlb size.
>
> Signed-off-by: Juergen Gross <jgr...@suse.com>
Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable
private objects")
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-...@lists.freedesktop.org
Cc: <drm-intel-fi...@lists.freedesktop.org> # v4.10-rc1+
We have a nice script for these :-)
-Daniel
> ---
> Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> with i915 graphics.
> ---
> drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> b/drivers/gpu/drm/i915/i915_gem_internal.c
> index 4b3ff3e..d09c749 100644
> --- a/drivers/gpu/drm/i915/i915_gem_internal.c
> +++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> @@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> drm_i915_gem_object *obj)
>
> max_order = MAX_ORDER;
> #ifdef CONFIG_SWIOTLB
> - if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> - max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> + if (swiotlb_nr_tbl()) {
> + unsigned int max_segment;
> +
> + max_segment = swiotlb_max_segment();
> + if (max_segment) {
> + max_segment = max_t(unsigned int, max_segment,
> + PAGE_SIZE) >> PAGE_SHIFT;
> + max_order = min(max_order, ilog2(max_segment));
> + }
> + }
> #endif
>
> gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 7/7] uapi: export all headers under uapi directories
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under uapi directories should be exported, thus it's > useless to have an exhaustive list. > > After this patch, the following files, which were not exported, are now > exported (with make headers_install_all): > asm-unicore32/shmparam.h > asm-unicore32/ucontext.h > asm-hexagon/shmparam.h > asm-mips/ucontext.h > asm-mips/hwcap.h > asm-mips/reg.h > drm/vgem_drm.h > drm/armada_drm.h > drm/omap_drm.h > drm/etnaviv_drm.h > asm-tile/shmparam.h > asm-blackfin/shmparam.h > asm-blackfin/ucontext.h > asm-powerpc/perf_regs.h > rdma/qedr-abi.h > asm-parisc/kvm_para.h > asm-openrisc/shmparam.h > asm-nios2/kvm_para.h > asm-nios2/ucontext.h > asm-sh/kvm_para.h > asm-sh/ucontext.h > asm-xtensa/kvm_para.h > asm-avr32/kvm_para.h > asm-m32r/kvm_para.h > asm-h8300/shmparam.h > asm-h8300/ucontext.h > asm-metag/kvm_para.h > asm-metag/shmparam.h > asm-metag/ucontext.h > asm-m68k/kvm_para.h > asm-m68k/shmparam.h > linux/bcache.h > linux/kvm.h > linux/kvm_para.h > linux/kfd_ioctl.h > linux/cryptouser.h > linux/kcm.h > linux/kcov.h > linux/seg6_iptunnel.h > linux/stm.h > linux/genwqe > linux/genwqe/.install > linux/genwqe/genwqe_card.h > linux/genwqe/..install.cmd > linux/seg6.h > linux/cifs > linux/cifs/.install > linux/cifs/cifs_mount.h > linux/cifs/..install.cmd > linux/auto_dev-ioctl.h > > Thanks to Julien Floret <julien.flo...@6wind.com> for the tip to get all > subdirs with a pure makefile command. > > Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com> Makes lots of sense. Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> > --- > Documentation/kbuild/makefiles.txt | 41 ++- > arch/alpha/include/uapi/asm/Kbuild | 41 --- > arch/arc/include/uapi/asm/Kbuild| 3 - > arch/arm/include/uapi/asm/Kbuild| 17 - > arch/arm64/include/uapi/asm/Kbuild | 18 -- > arch/avr32/include/uapi/asm/Kbuild | 20 -- > arch/blackfin/include/uapi/asm/Kbuild | 17 - > arch/c6x/include/uapi/asm/Kbuild| 8 - > arch/cris/include/uapi/arch-v10/arch/Kbuild | 5 - > arch/cris/include/uapi/arch-v32/arch/Kbuild | 3 - > arch/cris/include/uapi/asm/Kbuild | 43 +-- > arch/frv/include/uapi/asm/Kbuild| 33 -- > arch/h8300/include/uapi/asm/Kbuild | 28 -- > arch/hexagon/include/asm/Kbuild | 3 - > arch/hexagon/include/uapi/asm/Kbuild| 13 - > arch/ia64/include/uapi/asm/Kbuild | 45 --- > arch/m32r/include/uapi/asm/Kbuild | 31 -- > arch/m68k/include/uapi/asm/Kbuild | 24 -- > arch/metag/include/uapi/asm/Kbuild | 8 - > arch/microblaze/include/uapi/asm/Kbuild | 32 -- > arch/mips/include/uapi/asm/Kbuild | 37 --- > arch/mn10300/include/uapi/asm/Kbuild| 32 -- > arch/nios2/include/uapi/asm/Kbuild | 4 +- > arch/openrisc/include/asm/Kbuild| 3 - > arch/openrisc/include/uapi/asm/Kbuild | 8 - > arch/parisc/include/uapi/asm/Kbuild | 28 -- > arch/powerpc/include/uapi/asm/Kbuild| 45 --- > arch/s390/include/uapi/asm/Kbuild | 52 --- > arch/score/include/asm/Kbuild | 4 - > arch/score/include/uapi/asm/Kbuild | 32 -- > arch/sh/include/uapi/asm/Kbuild | 23 -- > arch/sparc/include/uapi/asm/Kbuild | 48 --- > arch/tile/include/asm/Kbuild| 3 - > arch/tile/include/uapi/arch/Kbuild | 17 - > arch/tile/include/uapi/asm/Kbuild | 19 +- > arch/unicore32/include/uapi/asm/Kbuild | 6 - > arch/x86/include/uapi/asm/Kbuild| 59 > arch/xtensa/include/uapi/asm/Kbuild | 23 -- > include/Kbuild | 2 - > include/asm-generic/Kbuild.asm | 1 - > include/scsi/fc/Kbuild | 0 > include/uapi/Kbuild | 15 - > include/uapi/asm-generic/Kbuild | 36 --- > include/uapi/asm-generic/Kbuild.asm | 62 ++-- > include/uapi/drm/Kbuild | 22 -- > include/uapi/linux/Kbuild | 482 > > include/uapi/linux/android/Kbuild | 2 - > include/uapi/linux/byteorder/Kbuild | 3 - > include/uapi/linux/caif/Kbuild | 3 - > include/uapi/linux/can/Kbuild
Re: [Xen-devel] [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs
On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
>
> This is fifth approach for replacing struct dma_attrs with unsigned
> long.
>
> The main patch (1/44) doing the change is split into many subpatches
> for easier review (2-42). They should be squashed together when
> applying.
For all the drm driver patches:
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Should I pull these in through drm-misc, or do you prefer to merge them
through a special topic branch (with everything else) instead on your own?
-Daniel
>
>
> Rebased on v4.7-rc5.
>
> For easier testing the patchset is available here:
> repo: https://github.com/krzk/linux
> branch: for-next/dma-attrs-const-v5
>
>
> Changes since v4
>
> 1. Collect some acks. Still need more.
> 2. Minor fixes pointed by Robin Murphy.
> 3. Applied changes from Bart Van Assche's comment.
> 4. More tests and builds (using https://www.kernel.org/pub/tools/crosstool/).
>
>
> Changes since v3
>
> 1. Collect some acks.
> 2. Drop wrong patch 1/45 ("powerpc: dma-mapping: Don't hard-code
>the value of DMA_ATTR_WEAK_ORDERING").
> 3. Minor fix pointed out by Michael Ellerman.
>
>
> Changes since v2
>
> 1. Follow Christoph Hellwig's comments (don't use BIT add
>documentation, remove dma_get_attr).
>
>
> Rationale
> =
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer. Thus the pointer can point to const
> data. However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
>
> 1. This is just simpler. Both in terms of reading the code and setting
>attributes. Instead of initializing local attributes on the stack
>and passing pointer to it to dma_set_attr(), just set the bits.
>
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.
>
>
> Best regards,
> Krzysztof
>
>
> Krzysztof Kozlowski (44):
> dma-mapping: Use unsigned long for dma_attrs
> alpha: dma-mapping: Use unsigned long for dma_attrs
> arc: dma-mapping: Use unsigned long for dma_attrs
> ARM: dma-mapping: Use unsigned long for dma_attrs
> arm64: dma-mapping: Use unsigned long for dma_attrs
> avr32: dma-mapping: Use unsigned long for dma_attrs
> blackfin: dma-mapping: Use unsigned long for dma_attrs
> c6x: dma-mapping: Use unsigned long for dma_attrs
> cris: dma-mapping: Use unsigned long for dma_attrs
> frv: dma-mapping: Use unsigned long for dma_attrs
> drm/exynos: dma-mapping: Use unsigned long for dma_attrs
> drm/mediatek: dma-mapping: Use unsigned long for dma_attrs
> drm/msm: dma-mapping: Use unsigned long for dma_attrs
> drm/nouveau: dma-mapping: Use unsigned long for dma_attrs
> drm/rockship: dma-mapping: Use unsigned long for dma_attrs
> infiniband: dma-mapping: Use unsigned long for dma_attrs
> iommu: dma-mapping: Use unsigned long for dma_attrs
> [media] dma-mapping: Use unsigned long for dma_attrs
> xen: dma-mapping: Use unsigned long for dma_attrs
> swiotlb: dma-mapping: Use unsigned long for dma_attrs
> powerpc: dma-mapping: Use unsigned long for dma_attrs
> video: dma-mapping: Use unsigned long for dma_attrs
> x86: dma-mapping: Use unsigned long for dma_attrs
> iommu: intel: dma-mapping: Use unsigned long for dma_attrs
> h8300: dma-mapping: Use unsigned long for dma_attrs
> hexagon: dma-mapping: Use unsigned long for dma_attrs
> ia64: dma-mapping: Use unsigned long for dma_attrs
> m68k: dma-mapping: Use unsigned long for dma_attrs
> metag: dma-mapping: Use unsigned long for dma_attrs
> microblaze: dma-mapping: Use unsigned long for dma_attrs
> mips: dma-mapping: Use unsigned long for dma_attrs
> mn10300: dma-mapping: Use unsigned long for dma_attrs
> nios2: dma-mapping: Use unsigned long for dma_attrs
> openrisc: dma-mapping: Use unsigned long for dma_attrs
> parisc: dma-mapping: Use unsigned long for dma_attrs
> misc: mic: dma-mapping: Use unsigned long for dma_attrs
> s390: dma-mapping: Use unsigned long for dma_attrs
> sh: dma-mapping: Use unsigned long for dma_attrs
> sparc: dma-mapping: Use unsigned long for dma_attrs
> tile: dma-mapping: Use unsigned long for dma_attrs
> unicore32: dma-mapping: Use unsigned long for dma_attrs
> xtensa: dma-mapping: Use unsigned long for dma_attrs
> dma-mapping: Remove dma_get_attr
> dma-mapping: Document the DMA attributes next to the declaration
>
> Documentation/DMA-API.txt | 33 +++---
> Documentation/DMA-attributes.txt | 2 +-
> arch/alp
Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
On Tue, Nov 24, 2015 at 03:12:31PM +0100, Gerd Hoffmann wrote: > Hi, > > > But there's some work to add generic mmap support to dma-bufs, and for > > really simple case (where we don't have a gl driver to handle the dma-buf > > specially) for untiled framebuffers that would be all we need? > > Not requiring gl is certainly a bonus, people might want build qemu > without opengl support to reduce the attach surface and/or package > dependency chain. > > And, yes, requirements for the non-gl rendering path are pretty low. > qemu needs something it can mmap, and which it can ask pixman to handle. > Preferred format is PIXMAN_x8r8g8b8 (qemu uses that internally in alot > of places so this avoids conversions). > > Current plan is to have a special vfio region (not visible to the guest) > where the framebuffer lives, with one or two pages at the end for meta > data (format and size). Status field is there too and will be used by > qemu to request updates and the kernel to signal update completion. > Guess I should write that down as vfio rfc patch ... > > I don't think it makes sense to have fields to notify qemu about which > framebuffer regions have been updated, I'd expect with full-screen > composing we have these days this information isn't available anyway. > Maybe a flag telling whenever there have been updates or not, so qemu > can skip update processing in case we have the screensaver showing a > black screen all day long. GL, wayland, X, EGL and soonish Android's surface flinger (hwc already has it afaik) all track damage. There's plans to add the same to the atomic kms api too. But if you do damage tracking you really don't want to support (maybe allow for perf reasons if the guest is stupid) frontbuffer rendering, which means you need buffer handles + damage, and not a static region. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
On Thu, Nov 19, 2015 at 01:02:36PM -0700, Alex Williamson wrote: > On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote: > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Thursday, November 19, 2015 2:12 AM > > > > > > [cc +qemu-devel, +paolo, +gerd] > > > > > > Another area of extension is how to expose a framebuffer to QEMU for > > > seamless integration into a SPICE/VNC channel. For this I believe we > > > could use a new region, much like we've done to expose VGA access > > > through a vfio device file descriptor. An area within this new > > > framebuffer region could be directly mappable in QEMU while a > > > non-mappable page, at a standard location with standardized format, > > > provides a description of framebuffer and potentially even a > > > communication channel to synchronize framebuffer captures. This would > > > be new code for QEMU, but something we could share among all vGPU > > > implementations. > > > > Now GVT-g already provides an interface to decode framebuffer information, > > w/ an assumption that the framebuffer will be further composited into > > OpenGL APIs. So the format is defined according to OpenGL definition. > > Does that meet SPICE requirement? > > > > Another thing to be added. Framebuffers are frequently switched in > > reality. So either Qemu needs to poll or a notification mechanism is > > required. > > And since it's dynamic, having framebuffer page directly exposed in the > > new region might be tricky. We can just expose framebuffer information > > (including base, format, etc.) and let Qemu to map separately out of VFIO > > interface. > > Sure, we'll need to work out that interface, but it's also possible that > the framebuffer region is simply remapped to another area of the device > (ie. multiple interfaces mapping the same thing) by the vfio device > driver. Whether it's easier to do that or make the framebuffer region > reference another region is something we'll need to see. > > > And... this works fine with vGPU model since software knows all the > > detail about framebuffer. However in pass-through case, who do you expect > > to provide that information? Is it OK to introduce vGPU specific APIs in > > VFIO? > > Yes, vGPU may have additional features, like a framebuffer area, that > aren't present or optional for direct assignment. Obviously we support > direct assignment of GPUs for some vendors already without this feature. For exposing framebuffers for spice/vnc I highly recommend against anything that looks like a bar/fixed mmio range mapping. First this means the kernel driver needs to internally fake remapping, which isn't fun. Second we can't get at the memory in an easy fashion for hw-accelerated compositing. My recoomendation is to build the actual memory access for underlying framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the host gpu driver again for rendering. For userspace the generic part would simply be an invalidate-fb signal, with the new dma-buf supplied. Upsides: - You can composit stuff with the gpu. - VRAM and other kinds of resources (even stuff not visible in pci bars) can be represented. Downside: Tracking mapping changes on the guest side won't be any easier. This is mostly a problem for integrated gpus, since discrete ones usually require contiguous vram for scanout. I think saying "don't do that" is a valid option though, i.e. we're assuming that page mappings for a in-use scanout range never changes on the guest side. That is true for at least all the current linux drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
On Tue, Nov 24, 2015 at 01:38:55PM +0100, Gerd Hoffmann wrote: > Hi, > > > > Yes, vGPU may have additional features, like a framebuffer area, that > > > aren't present or optional for direct assignment. Obviously we support > > > direct assignment of GPUs for some vendors already without this feature. > > > > For exposing framebuffers for spice/vnc I highly recommend against > > anything that looks like a bar/fixed mmio range mapping. First this means > > the kernel driver needs to internally fake remapping, which isn't fun. > > Sure. I don't think we should remap here. More below. > > > My recoomendation is to build the actual memory access for underlying > > framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the > > host gpu driver again for rendering. > > We want that too ;) > > Some more background: > > OpenGL support in qemu is still young and emerging, and we are actually > building on dma-bufs here. There are a bunch of different ways how > guest display output is handled. At the end of the day it boils down to > only two fundamental cases though: > > (a) Where qemu doesn't need access to the guest framebuffer > - qemu directly renders via opengl (works today with virtio-gpu > and will be in the qemu 2.5 release) > - qemu passed on the dma-buf to spice client for local display > (experimental code exists). > - qemu feeds the guest display into gpu-assisted video encoder > to send a stream over the network (no code yet). > > (b) Where qemu must read the guest framebuffer. > - qemu's builtin vnc server. > - qemu writing screenshots to file. > - (non-opengl legacy code paths for local display, will > hopefully disappear long-term though ...) > > So, the question is how to support (b) best. Even with OpenGL support > in qemu improving over time I don't expect this going away completely > anytime soon. > > I think it makes sense to have a special vfio region for that. I don't > think remapping makes sense there. It doesn't need to be "live", it > doesn't need support high refresh rates. Placing a copy of the guest > framebuffer there on request (and convert from tiled to linear while > being at it) is perfectly fine. qemu has a adaptive update rate and > will stop doing frequent update requests when the vnc client > disconnects, so there will be nothing to do if nobody wants actually see > the guest display. > > Possible alternative approach would be to import a dma-buf, then use > glReadPixels(). I suspect when doing the copy in the kernel the driver > could ask just the gpu to blit the guest framebuffer. Don't know gfx > hardware good enough to be sure though, comments are welcome. Generally the kernel can't do gpu blts since the required massive state setup is only in the userspace side of the GL driver stack. But glReadPixels can do tricks for detiling, and if you use pixel buffer objects or something similar it'll even be amortized reasonably. But there's some work to add generic mmap support to dma-bufs, and for really simple case (where we don't have a gl driver to handle the dma-buf specially) for untiled framebuffers that would be all we need? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
