On Sun, 27 Jan 2008 19:55:36 +0200
Pekka Paalanen <[EMAIL PROTECTED]> wrote:
> The following is a copy of the patch description:
...
> Mmiotrace works by wrapping the ioremap family of kernel functions and
> marking the returned pages as not present. Access to the IO memory
&g
c1157031b5dd01f49d4cb66 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen <[EMAIL PROTECTED]>
Date: Wed, 30 Jan 2008 21:49:52 +0200
Subject: [PATCH] x86: Add a list for custom page fault handlers.
Provides kernel modules a way to register custom page fault handlers.
On every page fault this
the "undefined symbol
init_mm" problem on 32-bit, but we just put the export back in (not
included in these patches).
No-one has tried this on SMP. I have a Core 2 Duo laptop where I will
test this when I get the chance.
>From 1bf67af4900b75a56cb47726d7b63d11d7e8 Mon Sep 17 00:00:
On Thu, 31 Jan 2008 08:15:07 -0800
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Jan 2008 18:02:53 +0200
> Pekka Paalanen <[EMAIL PROTECTED]> wrote:
> >
> > Very well, first the revised custom page fault handler patch.
> > Changes since the previous
On Thu, 31 Jan 2008 08:29:06 -0800
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Jan 2008 18:16:30 +0200
> Pekka Paalanen <[EMAIL PROTECTED]> wrote:
>
> > And here's mmiotrace. This works for me (amd64), but not for a test
> > user who has 32-
daunting.
Thanks, I'll do what I can. When do you need the final (as for 2.6.25)
mmiotrace patch, or is it going in as v2 and then we fix it in RCs?
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Use lookup_address() from pageattr.c instead of doing the same
manually. Also had to EXPORT_SYMBOL(lookup_address) to make this
work for modules. This also fixes "undefined symbol 'init_mm'"
compile error for x86_32.
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
Relay has per-cpu buffers, but mmiotrace was using only a single flag
for detecting buffer full/not-full transitions. The new code makes
this per-cpu and actually counts missed events.
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
arch/x86/kernel/mmiotrace/mmio-mod.c
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
include/linux/mmiotrace.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/mmiotrace.h b/include/linux/mmiotrace.h
index cb24782..6ec288f 100644
--- a/include/linux/mmiotrace.h
+++ b/include
this directly to your email, if you wish.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
On Tue, 05 Feb 2008 21:44:07 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Pekka Paalanen a écrit :
> > diff --git a/arch/x86/kernel/mmiotrace/mmio-mod.c
> > b/arch/x86/kernel/mmiotrace/mmio-mod.c
> > index 82ae920..f492b65 100644
> > --- a/arch/x86/kernel/mm
The custom page fault handler list is replaced with a single function
pointer. All related functions and variables are renamed for
mmiotrace.
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.debug | 14 -
arch/x86/mm/fault.c
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
arch/x86/mm/kmmio.c| 27 +---
arch/x86/mm/mmio-mod.c | 80 +--
2 files changed, 58 insertions(+), 49 deletions(-)
diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
qrestore(&mmiotrace_handler_lock, flags);
> > + return ret;
> > }
> > +EXPORT_SYMBOL_GPL(mmiotrace_register_pf);
>
> why not use a weak function instead? should be a ton simpler.
Ookay, this is the first time I hear about weak functions, and
that I could accomplish
On Sat, 9 Feb 2008 20:56:07 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi Pekka,
>
> On Feb 9, 2008 8:23 PM, Pekka Paalanen <[EMAIL PROTECTED]> wrote:
> > By default it reserves 32 MB/cpu of relay buffers during module init.
> > It's t
The custom page fault handler list is replaced with a single function
pointer. All related functions and variables are renamed for
mmiotrace.
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
On Sat, 09 Feb 2008 19:39:30 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> So her
whole.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
c
new file mode 100644
index 000..539a9b1
--- /dev/null
+++ b/arch/x86/mm/kmmio.c
@@ -0,0 +1,541 @@
+/* Support for MMIO probes.
+ * Benfit many code from kprobes
+ * (C) 2002 Louis Zhuang <[EMAIL PROTECTED]>.
+ * 2007 Alexander Eichner
+ * 2008 Pekka Paalanen <[EMAIL PROTECTED]&
mizing
it away. Now thinking it again, ioread*() must guarantee that the read
is always executed. I'll remove v altogether.
Patch for the other issues you mentioned is brewing.
Thanks.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "uns
e keep me in CC. Also I CC'd the people
who wrote about the same issue in the past.
Thanks.
[1] http://nouveau.freedesktop.org/wiki/MmioTrace
[2] http://marc.info/?l=linux-kernel&m=119540769014745&w=2
[3] http://article.gmane.org/gmane.linux.kernel/609521
--
Pekka Paalanen
y bothers me
in the case of mmio-trace. The probe will actually service the page
fault, therefore it should be able force do_page_fault() to return at
the probe point. I could not figure out a way to do that.
Is it possible to do reliably with kprobes or markers?
Thanks for the replies.
--
Pek
'll see how far I get before 2.6.25 closes. I'm new to all this and
will need help, especially in making mmio-trace SMP-safe, for instance.
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
From: Pekka Paalanen <[EMAIL PROTECTED]>
Provides kernel modules a way to register custom page fault handlers.
On every page fault, except those handled in vmalloc_fault(), this will
call a list of registered functions. The functions may handle the fault
and force do_page_fault() to
Hello,
the patch itself is slightly bigger than recommended for LKML, so
it is available at:
http://jumi.lut.fi/~paalanen/scratch/mmio24/0002-x86-mmiotrace-trace-memory-mapped-IO.patch.txt
This seems to work fine on UP machine, I have not tested yet with
with an SMP machine. Originally mmio-trace
hoping distros would ship some kernels with PAGE_FAULT_HANDLERS
enabled as it would make contributors' lives easier. IIRC some
already have enabled RELAY and DEBUG_FS for mmiotrace. This is why I
think keeping the performance impact to the minimum here is important,
for the case of no custom handlers registered.
Thanks,
--
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 19 Aug 2020 17:53:36 -0300
Melissa Wen wrote:
> The current VKMS blend function ignores alpha channel and just overwrites
> vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
> running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT
> tests, cairo_format_ar
On Sat, 27 Mar 2021 11:26:26 +
Paul Cercueil wrote:
> It has two mutually exclusive background planes (same Z level) + one
> overlay plane.
What's the difference between the two background planes?
How will generic userspace know to pick the "right" one?
Thanks,
pq
> Le sam. 27 mars 2021
On Mon, 29 Mar 2021 12:41:00 +0100
Paul Cercueil wrote:
> Hi,
>
> Le lun. 29 mars 2021 à 11:15, Pekka Paalanen a
> écrit :
> > On Sat, 27 Mar 2021 11:26:26 +
> > Paul Cercueil wrote:
> >
> >> It has two mutually exclusive background planes (
On Mon, 29 Mar 2021 15:36:27 +
Simon Ser wrote:
> On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
> wrote:
>
> > Making the second plane an overlay would break the ABI, which is never
> > something I'm happy to do; but I'd prefer to do it now than later.
>
> Yeah, I wonder if some
On Mon, 5 Apr 2021 11:41:50 +0530
Sumera Priyadarsini wrote:
> This patchset adds support for emulating virtual hardware with VKMS.
> The virtual hardware mode can be enabled by using the following command
> while loading the module:
> sudo modprobe vkms enable_virtual_hw=1
Hi,
every ti
On Wed, 27 Jan 2021 12:01:55 +0100
Christian König wrote:
> Somewhat correct. This interface here really doesn't make sense since
> the file descriptor representation of DMA-buf is only meant to be used
> for short term usage.
>
> E.g. the idea is that you can export a DMA-buf fd from your dev
On Wed, 4 May 2016 14:17:13 -0500
Bjorn Helgaas wrote:
> 138295373ccf ("ftrace: mmiotrace update, #2") added this use of
> pci_resource_to_user():
>
> +static int mmio_print_pcidev(struct trace_seq *s, const struct pci_dev
> *dev)
> +{
> ...
> + /*
> +* XXX: is pci_resou
On Tue, 31 May 2016 08:29:20 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Why attach the hotspot to the plane? Wouldn't it make more sense to
> > > make it a framebuffer property?
> >
> > We don't have properties on the framebuffer. I guess you /could/ just add
> > it internally to struct drm_
platform/olpc/olpc-xo15-sci.c | 2 +-
> arch/x86/platform/sfi/sfi.c| 3 +--
> arch/x86/xen/debugfs.c | 2 +-
> arch/x86/xen/setup.c | 2 +-
> 16 files changed, 63 insertions(+), 75 deletions(-)
>
Hi,
seems fine to me, even though I haven&#
On Wed, 1 Jul 2020 12:45:48 -0700
James Jones wrote:
> OK, I think I see what's going on. In the Xorg modesetting driver, the
> logic is basically:
>
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
>drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
>
On Wed, 3 Jun 2020 17:25:47 +0800
Chuhong Yuan wrote:
> Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory()
> partly, it does not call pci_disable_device() as gx1fb_map_video_memory()
> calls pci_enable_device().
> Add the missed function call to fix the bug.
>
> Fixes: 5
On Wed, 26 Aug 2020 22:23:28 +0800
Algea Cao wrote:
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
>
> Signed-off-by: Algea Cao
> ---
>
> drivers/gpu/drm/drm_edid.c | 45 +
> include/drm
On Wed, 12 Aug 2020 16:30:17 +0300
Laurent Pinchart wrote:
> Hi Algea,
>
> On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote:
> > 在 2020/8/12 17:33, Laurent Pinchart 写道:
> > > On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote:
> > >> Introduce struct dw_hdmi_property_ops in plat_da
On Thu, 13 Aug 2020 13:45:22 +0300
Laurent Pinchart wrote:
> On Thu, Aug 13, 2020 at 10:42:28AM +0300, Pekka Paalanen wrote:
> > On Wed, 12 Aug 2020 16:30:17 +0300 Laurent Pinchart wrote:
> > > On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote:
> > > > 在 2020/
On Tue, 20 Oct 2020 14:13:44 +0530
Mugilraj Dhavachelvan wrote:
> Replacing return value -1 to error code
>
> Signed-off-by: Mugilraj Dhavachelvan
> ---
> arch/x86/mm/kmmio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> i
On Tue, 18 Apr 2017 12:00:17 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > > only format supported by bochs-drm), and we have to interpret that
On Tue, 18 Apr 2017 15:39:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > > here, it drives the qemu stdvga with offb, not bochs-drm.
> >
> > I suppose this proves the virtual machine itself is correct about
> > framebuf
On Wed, 19 Apr 2017 10:01:47 +0900
Michel Dänzer wrote:
> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Quite true that this proves nothing. However one should note that
> >>> fbcon -> fbdev works,
> >>
> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code
s as-is. I have no idea if and how those are used
> on bigendian machines.
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ilia Mirkin
> Cc: Michel Dänzer
> Cc: Alex Deucher
> Cc: amd-...@lists.freedeskt
On Fri, 21 Apr 2017 14:08:04 +0300
Ville Syrjälä wrote:
> On Fri, Apr 21, 2017 at 11:50:18AM +0200, Gerd Hoffmann wrote:
> > On Fr, 2017-04-21 at 12:25 +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 21, 2017 at 09:58:24AM +0200, Gerd Hoffmann wrote:
> > > > While working on graphics support fo
On Mon, 10 Apr 2017 12:12:01 +0200
Gerd Hoffmann wrote:
> Ok, this is really a kickstart for a discussion. While working on
> graphics support for virtual machines on ppc64 (which exists in both
> little and big endian variants) I've figured the comments in the header
> file don't match reality.
On Mon, 10 Apr 2017 16:17:27 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > which software have you used as representative of "reality"?
>
> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> only form
On Mon, 10 Apr 2017 12:10:14 -0400
Ilia Mirkin wrote:
> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote:
> > I also wonder if a real BE machine could have different results than
> > the virtual machine.
>
> I have a PPC G5 with an AGP GeForce FX 5200 that I can
On Tue, 11 Apr 2017 13:23:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Just let know what you need tested, I should be able to turn it around
> > > within a couple of days.
> >
> > That's part of my problem. I don't really know what should be tested.
> > What do people do with their BE machi
On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > >(a) software rendering: client allocates shared memory buffer, renders
> > >into it, then passes a file handle for that shmem block together
> > >with some meta data (size, format, ...) to the wayland serv
On Mon, 5 Feb 2018 17:03:22 +0100
Gerd Hoffmann wrote:
> On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
> > >Hi,
> > >
>
> Hmm. I allways assumed the wayland client allocates the buffers, not
> the server. Is that wrong?
On Tue, 2 May 2017 14:53:43 +0100
Emil Velikov wrote:
> Hi Gerd,
>
> I did not have the change to follow through the discussion.
> Pardon if my suggestion have already been discussed.
>
> On 2 May 2017 at 14:34, Gerd Hoffmann wrote:
> > It's unused.
> >
> > Suggested-by: Daniel Vetter
> > Sig
52 matches
Mail list logo
