On Sat, 2007-01-06 at 19:31 +, Christoph Hellwig wrote:
> On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> > PS. drm_memory.h has a "drm_follow_page": this forces us to uninline
> > various page tables ops. Can this use follow_page() somehow, or do we
> > need an "__follow_pag
Even better we can actualy avid most of the page table walks completely.
First there is a number of places that can never have the vmalloc case
an may use ioremap/iounmap directly. Secondly drm_core_ioremap/
drm_core_ioremapfree already have the right drm_map to check wich kind
of mapping we ha
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 06, 2007 at 07:31:52PM +, Christoph Hellwig wrote:
> > On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> > > PS. drm_memory.h has a "drm_follow_page": this forces us to uninline
> > > various page tables ops. Can th
On Sat, Jan 06, 2007 at 07:31:52PM +, Christoph Hellwig wrote:
> On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> > PS. drm_memory.h has a "drm_follow_page": this forces us to uninline
> > various page tables ops. Can this use follow_page() somehow, or do we
> > need an "__fol
Rusty Russell wrote:
On Sat, 2007-01-06 at 12:55 -0800, Zachary Amsden wrote:
Rusty Russell wrote:
+int paravirt_write_msr(unsigned int msr, u64 val);
If binary modules using debug registers makes us nervous, the
reprogramming MSRs is also similarly bad.
Yes, but this is
On Sat, 2007-01-06 at 12:55 -0800, Zachary Amsden wrote:
> Rusty Russell wrote:
> >
> > +int paravirt_write_msr(unsigned int msr, u64 val);
>
> If binary modules using debug registers makes us nervous, the
> reprogramming MSRs is also similarly bad.
Yes, but this is simply from experience. Seve
Rusty Russell wrote:
+int paravirt_write_msr(unsigned int msr, u64 val);
If binary modules using debug registers makes us nervous, the
reprogramming MSRs is also similarly bad.
+void raw_safe_halt(void);
+void halt(void);
These shouldn't be done by modules, ever. Only the scheduler
On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> PS. drm_memory.h has a "drm_follow_page": this forces us to uninline
> various page tables ops. Can this use follow_page() somehow, or do we
> need an "__follow_page" export for this case?
Not if avoidable. And it seems avoidable
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> I moved drm_follow_page into the core, to avoid having to wrap the
> various pte ops. Unlining kernel_fpu_end and using that in the RAID6
> code would remove the need to export clts/read_cr0/write_cr0 too.
yeah, let's do that too.
Ingo
-
T
On Sat, 2007-01-06 at 08:08 +0100, Ingo Molnar wrote:
> btw., your patch does not apply to current -git - could you please
> rebase this patch to the head of your queue so that upstream can pick it
> up?
OK, here it is against rc3-git4.
Name: don't export paravirt_ops structure, do individual f
On Sat, 2007-01-06 at 08:14 +0100, Ingo Molnar wrote:
> * Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > +EXPORT_SYMBOL(clts);
> > +EXPORT_SYMBOL(read_cr0);
> > +EXPORT_SYMBOL(write_cr0);
>
> mark these a _GPL export. Perhaps even mark the symbol deprecated, to be
> unexported once we fix raid6.
On Sat, 2007-01-06 at 01:50 -0800, Zachary Amsden wrote:
> Ingo Molnar wrote:
> > * Rusty Russell <[EMAIL PROTECTED]> wrote:
> >
> >
> >> +EXPORT_SYMBOL(clts);
> >> +EXPORT_SYMBOL(read_cr0);
> >> +EXPORT_SYMBOL(write_cr0);
> >>
> >
> > mark these a _GPL export. Perhaps even mark the symbol
Ingo Molnar wrote:
* Rusty Russell <[EMAIL PROTECTED]> wrote:
+EXPORT_SYMBOL(clts);
+EXPORT_SYMBOL(read_cr0);
+EXPORT_SYMBOL(write_cr0);
mark these a _GPL export. Perhaps even mark the symbol deprecated, to be
unexported once we fix raid6.
read / write cr0 must not be GPL, since
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> +EXPORT_SYMBOL(clts);
> +EXPORT_SYMBOL(read_cr0);
> +EXPORT_SYMBOL(write_cr0);
mark these a _GPL export. Perhaps even mark the symbol deprecated, to be
unexported once we fix raid6.
> +EXPORT_SYMBOL(wbinvd);
> +EXPORT_SYMBOL(raw_safe_halt);
> +EXPOR
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> this doesnt do the most crutial step: the removal of the paravirt_ops
> export. [...]
ah, you removed it already ... it hid at the very last line of the patch
chunk. Good :)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe lin
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> diff -r 48f31ae5d7b5 arch/i386/kernel/paravirt.c
> --- a/arch/i386/kernel/paravirt.c Sat Jan 06 10:32:24 2007 +1100
> +++ b/arch/i386/kernel/paravirt.c Sat Jan 06 17:23:12 2007 +1100
> @@ -596,6 +596,154 @@ static int __init print_banner(void)
On Fri, 2007-01-05 at 16:31 -0800, Zachary Amsden wrote:
> Ingo Molnar wrote:
> > Subject: [patch] paravirt: isolate module ops
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> >
> > only export those operations to modules that have been available to them
> > his
On Fri, 2007-01-05 at 18:07 -0800, Arjan van de Ven wrote:
> >
> > I would suggest a slightly different carving. For one, no TLB flushes.
> > If you can't modify PTEs, why do you need to have TLB flushes? And I
> > would allow CR0 read / write for code which saves and restores FPU state
>
>
Arjan van de Ven wrote:
I would suggest a slightly different carving. For one, no TLB flushes.
If you can't modify PTEs, why do you need to have TLB flushes? And I
would allow CR0 read / write for code which saves and restores FPU state
no that is abstracted away by kernel_fpu_begin/e
>
> I would suggest a slightly different carving. For one, no TLB flushes.
> If you can't modify PTEs, why do you need to have TLB flushes? And I
> would allow CR0 read / write for code which saves and restores FPU state
no that is abstracted away by kernel_fpu_begin/end. Modules have no
bu
Ingo Molnar wrote:
Subject: [patch] paravirt: isolate module ops
From: Ingo Molnar <[EMAIL PROTECTED]>
only export those operations to modules that have been available to them
historically: irq disable/enable, io-delay, udelay, etc.
this isolates that functionality from
Ingo Molnar wrote:
Subject: [patch] paravirt: isolate module ops
From: Ingo Molnar <[EMAIL PROTECTED]>
only export those operations to modules that have been available to them
historically: irq disable/enable, io-delay, udelay, etc.
this isolates that functionality from
Subject: [patch] paravirt: isolate module ops
From: Ingo Molnar <[EMAIL PROTECTED]>
only export those operations to modules that have been available to them
historically: irq disable/enable, io-delay, udelay, etc.
this isolates that functionality from other paravirtualization
functio
23 matches
Mail list logo
