Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943103AbcJ1WHy (ORCPT ); Fri, 28 Oct 2016 18:07:54 -0400 Received: from fallback8.mail.ru ([94.100.181.110]:34785 "EHLO fallback8.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942390AbcJ1WHw (ORCPT ); Fri, 28 Oct 2016 18:07:52 -0400 X-Greylist: delayed 1856 seconds by postgrey-1.27 at vger.kernel.org; Fri, 28 Oct 2016 18:07:51 EDT Subject: Re: /dev/mem and PCI memory = EFAULT (regression?) To: Andy Lutomirski References: <52478c6c-39cb-35b1-0517-33d9f6e99a5a@list.ru> Cc: Linux kernel , Linus Torvalds , dosemu-devel , Bart Oldeman , "Eric W. Biederman" From: Stas Sergeev Message-ID: <89281ddd-ea21-6de8-b4dd-57ff4b0d2040@list.ru> Date: Sat, 29 Oct 2016 00:36:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: smtp14.mail.ru; auth=pass smtp.auth=stsp@list.ru smtp.mailfrom=stsp@list.ru X-E1FCDC63: 26BB07C17A5E6E6E6953D750749AB125074A40F52AF1438D X-E1FCDC64: DFE3739730BDA9467D16EC24265F987AFB8DAACEF07967E7F54D2F1F68F62888B58C0E165F9F46AE X-Mailru-Sender: CD12F6D16A91A659C71BA12F480A5E3EE38465F8DBB470B044467B2F5A1C9BFA58F5CF629839BB2508D917D6130B1AFB X-Mras: OK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2156 Lines: 50 OK, thanks for the prompt reply, Andy! I'll try your sysfs suggestion. Let me just add a bit of CCs to get more people involved. I believe the ram size involvement makes this smell like a bug, plus it looks like a regression. Not that I am going to suffer much (this pass-through stuff always breaks in a million of different ways, I'll probably just remove it), but its still a very questionable change IMO. 29.10.2016 00:26, Andy Lutomirski пишет: > On Fri, Oct 28, 2016 at 2:18 PM, Stas Sergeev wrote: >> 29.10.2016 00:05, Andy Lutomirski пишет: >> >>> On Fri, Oct 28, 2016 at 2:03 PM, Stas Sergeev wrote: >>>> Hello. >>>> >>>> For the long time dosemu used /dev/mem for vga pass-through. >>>> Now it appears /dev/mem has this check: >>>> http://lxr.free-electrons.com/source/drivers/char/mem.c#L51 >>>> which prevents an accesses to PCI memory regions if the >>>> "high_memory" points low enough. It seems "high_memory" >>>> just points to the end of the physical ram, so depending on >>>> the ram size you either can access PCI devices or you get >>>> EFAULT. >>>> Was it wrong to use /dev/mem for accessing the PCI devices? >>>> How should I do that now? >>>> >>> What is DOSEMU trying to do here? Access the framebuffer? >>> >>> ISTM it would be better to use the DRM or FB layer directly (just map >>> the framebuffer itself) or, if necessary, use VFIO. >> Yes, framebuffer. >> Mapping fb directly is not really an option because dosemu does >> its own modesetting when you do vga pass-through. So it is >> usually started that way with "nomodeset=1" and w/o fb. >> Yes, some crazy people try the pass-through even out of fb >> console, but that's weird (the problem is most SDL2 builds do >> not have directfb backend compiled in, otherwise we could >> just use SDL rendering on top of fb). >> >> The thing is, I needed (for testing purposes, unrelated to dosemu) >> some quick way to access the PCI memory space, and to my surprise I >> couldn't do that with /dev/mem. Was this really disallowed intentionally? > I believe so. > > Try the /sys/devices/.../resource? and resource?_wc files. > > --Andy >