mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Tobias Powalowski <t.powa@gmx.de>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/paravirt: revert exports to restore old behaviour
Date: Tue, 13 Nov 2007 16:51:04 -0800	[thread overview]
Message-ID: <1195001464.6352.109.camel@bodhitayantram.eng.vmware.com> (raw)
In-Reply-To: <20071113222212.GA1322@infradead.org>

On Tue, 2007-11-13 at 22:22 +0000, Christoph Hellwig wrote:
> On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
> > Subject: x86/paravirt: revert exports to restore old behaviour
> > 
> > Subdividing the paravirt_ops structure caused a regression in certain
> > non-GPL modules which try to use mmu_ops and cpu_ops.  This restores
> > the old behaviour, and makes it consistent with the
> > non-CONFIG_PARAVIRT case.
> 
> NACK, both of these are internal and graphics drivers should not be
> using them.

Some of them are internal, but some are not, they just happened to be
privileged CPU operations available to anyone.

Does anyone know what hooks they are actually using?  Something like
reading MSRs is not internal at all, it is CPU specific, and the
graphics drivers might have very good reasons to read them to figure out
how AGP is configured for example.

The graphics drivers most certainly don't need to be paravirtualized
however, so they could always work around this with raw asm constructs.

The mmu_ops hook is more debatable.  But until someone figures out what
hooks they want, we can't know whether they are internal or not.  In any
case, this is a regression.

Zach


  reply	other threads:[~2007-11-14  0:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 10:39 REGRESSION: 2.6.24 breaks nvidia and amd/ati binary drivers, by exporting paravirt symbols as GPL Tobias Powalowski
2007-11-13 20:21 ` [PATCH] x86/paravirt: revert exports to restore old behaviour Jeremy Fitzhardinge
2007-11-13 22:22   ` Christoph Hellwig
2007-11-14  0:51     ` Zachary Amsden [this message]
2007-11-19 17:05       ` Takashi Iwai
2007-11-20  1:14         ` Jeremy Fitzhardinge
2007-11-20  6:25           ` Takashi Iwai
2007-11-14  1:22     ` Jeremy Fitzhardinge
2007-11-27 22:57 Jeremy Fitzhardinge
2007-11-28 20:40 ` Adrian Bunk
2007-11-28 21:15   ` Jeremy Fitzhardinge
2007-11-28 22:39     ` Adrian Bunk
2007-11-28 23:57       ` Jeremy Fitzhardinge
2007-11-29 22:06         ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1195001464.6352.109.camel@bodhitayantram.eng.vmware.com \
    --to=zach@vmware.com \
    --cc=hch@infradead.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=t.powa@gmx.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®