Implement vmi_kmap_atomic_pte in terms of the backend set_linear_mapping
operation. The conversion is rather straighforward; call kmap_atomic
and then inform the hypervisor of the page mapping.
The _flush_tlb damage is due to macros being pulled in from highmem.h.
Signed-off-by: Zachary Amsden
Latest cleanups and junk from Zach's tree. All for -mm tree.
Based off Jeremy's latest known applied patches. If the
paravirt or VMI patches reject let me know; we are cleaning up
tree and will redo.
Otherwise, I have 4 fixes for i386; a warning fix in sysenter
which is quite serious; some less
Don't implement native_kmap_atomic_pte for !HIGHPTE case; it is never needed,
never called, and leaving it in is just plain confusing. Making it isolated
to the config where it is used may help find bugs.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 5c03805411a6 arch/
In compat mode, the return value here was uninitialized.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 1fda49a076ed arch/i386/kernel/sysenter.c
--- a/arch/i386/kernel/sysenter.c Fri Apr 06 14:25:09 2007 -0700
+++ b/arch/i386/kernel/sysenter.c Fri Apr 06 14:27:3
In light of objections to the original fix I proposed for lazy MMU
interactions between VMI and kmap_atomic in interrupt context, I
have an updated patch series.
The first is for 2.6.21; it is an urgent bugfix, please apply.
The second backs out the first; it is required to avoid conflicts
with
.6.22, as it causes conflicts. An updated patch will be re-merged
after the queue.
Thanks to Jeremy Fitzhardinge for noting the bug and suggestions on a fix.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r be8c61492e28 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri M
. This is dependent on changes which have not
yet been merged.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r ecb571084874 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri Apr 06 12:31:06 2007 -0700
+++ b/arch/i386/kernel/vmi.cFri Apr 06 12:31:06 2007 -0700
@@ -69,6
Revert the last patch; it is only for 2.6.21, and an updated version will
be merged for 2.6.22. Do this before applying other i386 paravirt-ops
patches to avoid merge conflicts caused by code movement and cleanup.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 88bdf8174a2d arc
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Do you mean kmap_atomic_pfn?
Yes.
kunmap_atomic can stay lazy (at least for VMI), actually, but it
doesn't help since it happens outside the spin lock.
May as well be consistent. Or do you mean you can't flush o
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Throw it in the queue; I'll slide in after it.
I've pushed it up. I added a few missing cases to the patch
(kmap_atomic_pte, kunmap_atomic).
Do you mean kmap_atomic_pfn? kunmap_atomic can stay lazy (at least for
VMI)
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Ok, I tried that and I got a nice clean fix. For 2.6.22
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Throw it in the queue; I'll slide in after it.
Zach
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
So the clean fix for this is still even further out. I don't think I
want to hook kmap/unmap as paravirt-ops.
Yes, it seems like overkill.
How about something like adding PARAVIRT_LAZY_FLUSH as an argument to
set_lazy_mode? It
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
No, they are totally dependent. The reason interrupts are disabled is
to stop kmap_atomic in interrupt handlers. With the kmap_atomic_pte
changes, the whole interrupt disable jibberish goes away.
But kmap_atomic_pte is a special case
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Well at this point, the "proper" fix is dependent on Jeremy's
kmap_atomic_pte changes, which are definitely too late to pull into
2.6.21. Can we just apply this patch please?
Hm, I think they're independent aren&
Andi Kleen wrote:
On Friday 06 April 2007 01:29:56 Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21.
I think it is. That is
Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
is needed as a bugfix in 2.6.21. An updated version for
can be used to disable interrupts
during this critical region.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: ubuntu-2.6.20/arch/i386/kernel/vmi.c
===
--- ubuntu-2.6.20.orig/arch/i386/kernel/vmi.c 2007-03-29
H. Peter Anvin wrote:
>
> I actually expect rdmsr/wrmsr to have a higher likelihood of weird
> things. I don't know how many hypervisors can trap and handle those.
Or implement anything useful at all ... perhaps it might be useful to
simply wrap them with an -ENOSYS in some cases.
Rusty, Jerem
H. Peter Anvin wrote:
>
> It seems to me that perhaps this is the way to do it:
>
> - Add cpuid_everything, rdmsr_everything and wrmsr_everything
> entrypoints;
Yes, although I think we can omit rdmsr / wrmsr.
>
> - Provide compatibility wrappers that simply invoke the cpuid, rdmsr,
> and wrm
H. Peter Anvin wrote:
>
> I guess what I was trying to say was that we'd use setgpr_wrapper in
> the case where you have an entrypoint with native (non-C) semantics;
> in the other case we'd use an alternative to setgpr_wrapper. Either
> way, it sounds like we're talking about implementing
> p
H. Peter Anvin wrote:
>
> This code is almost entirely identical to the setgpr_wrapper in the
> patch (except for the fact that setgpr_wrapper sets and captures *ALL*
> the GPRs), and it seems rather pointless to use another wrapper. It
> takes a pointer to an entrypoint (default to "cpuid; ret
H. Peter Anvin wrote:
> It's not *quite* that easy. The assembly code around this is pretty
> extensive, because it has to stand on its head in order to present the
> proper register image.
>
Having just stood on my head for 55 breaths, might I suggest we
implement a binary equivalent CPUID
H. Peter Anvin wrote:
> I have finally gotten off the pot and finished writing up my new
> CPUID/MSR driver, which contains support for registers that need
> arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an
> x86-64 register image (16 64-bit register fields); this allows 32
Andi Kleen wrote:
I think I would prefer you touch the generic code. This new hook is ugly.
What new hook? The hook has been there for sometime, and now we are
using it to fix a bug. I do not want to touch generic or arch code at
this point in the 2.6.21 release.
And the lazy mode is c
Jeremy Fitzhardinge wrote:
The comment only talks about disabling interrupts for lazy_mmu, but this
seems to do it for lazy_cpu as well. Is that OK? What happens if
someone wants to change interrupt states under lazy_cpu; I can't think
of an inherent reason why that wouldn't be allowed (though
-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r be8c61492e28 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cFri Mar 30 14:13:45 2007 -0700
+++ b/arch/i386/kernel/vmi.cFri Mar 30 14:18:16 2007 -0700
@@ -69,6 +69,7 @@ struct {
void (*flush_tlb)(int);
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than comparative benchmarking on systems
without graph
Jeremy Fitzhardinge wrote:
> Do you disable interrupts when lazy_mmu is active? Otherwise, it seems
> to me that drivers will have problems using kmap_atomic() within an
> interrupt routine...
>
Yup, that's a pretty serious bug. Looks like the lazy mmu code needs to
save and restore interrup
David Rientjes wrote:
Date: Sun, 25 Mar 2007 23:07:43 -0800
From: Zachary Amsden <[EMAIL PROTECTED]>
If you actually clear the bit, you need to:
+ pte_update_defer(vma->vm_mm, addr, ptep);
The reason is, when updating PTEs, the hyperv
David Rientjes wrote:
On Sun, 25 Mar 2007, Zachary Amsden wrote:
If you actually clear the bit, you need to:
+ pte_update_defer(vma->vm_mm, addr, ptep);
The reason is, when updating PTEs, the hypervisor must be notified. Using
atomic operations to do this is fine for
Hugh Dickins wrote:
On Sun, 25 Mar 2007, Zachary Amsden wrote:
If you actually clear the bit, you need to:
+ pte_update_defer(vma->vm_mm, addr, ptep);
The reason is, when updating PTEs, the hypervisor must be notified. Using
atomic operations to do this is fine for all hypervis
Hugh Dickins wrote:
On Sun, 25 Mar 2007, David Rientjes wrote:
Add ptep_test_and_clear_{dirty,young} to i386. They advertise that they
have it and there is at least one place where it needs to be called
without the page table lock: to clear the accessed bit on write to
Without the pag
Jeremy Fitzhardinge wrote:
> The softlockup watchdog is currently a nuisance in a virtual machine,
> since the whole system could have the CPU stolen from it for a long
> period of time. While it would be unlikely for a guest domain to be
> denied timer interrupts for over 10s, it could happen and
Jeremy Fitzhardinge wrote:
The softlockup watchdog is currently a nuisance in a virtual machine,
since the whole system could have the CPU stolen from it for a long
period of time. While it would be unlikely for a guest domain to be
denied timer interrupts for over 10s, it could happen and any s
Linus Torvalds wrote:
> On Tue, 20 Mar 2007, Zachary Amsden wrote:
>
>> Actually, I was thinking the irq handlers would just not mess around with
>> eflags on the stack, just call the chip to ack the interrupt and re-enable
>> hardware interrupts when they left, since
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
Actually, I was thinking the irq handlers would just not mess around with
eflags on the stack, just call the chip to ack the interrupt and re-enable
hardware interrupts when they left, since that is free anyway with the iret
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
Actually, I was thinking the irq handlers would just not mess around with
eflags on the stack, just call the chip to ack the interrupt and re-enable
hardware interrupts when they left, since that is free anyway with the iret
Linus Torvalds wrote:
> On Tue, 20 Mar 2007, Zachary Amsden wrote:
>
>> void local_irq_restore(int enabled)
>> {
>>pda.intr_mask = enabled;
>>/*
>> * note there is a window here where softirqs are not processed by
>> * the interrupt ha
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
void local_irq_restore(int enabled)
{
pda.intr_mask = enabled;
/*
* note there is a window here where softirqs are not processed by
* the interrupt handler, but that is not a problem, since it will
* get done
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Zachary Amsden wrote:
void local_irq_restore(int enabled)
{
pda.intr_mask = enabled;
/*
* note there is a window here where softirqs are not processed by
* the interrupt handler, but that is not a problem, since it will
* get done
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I think Jeremy's idea was to have interrupt handlers leave interrupts
disabled on exit if pda.intr_mask was set. In which case, they would
bypass all work and we could never get preempted.
Yes, I was worried that if we left th
Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>
>> I think Jeremy's idea was to have interrupt handlers leave interrupts
>> disabled on exit if pda.intr_mask was set. In which case, they would
>> bypass all work and we could never get preempted.
>>
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I think Jeremy's idea was to have interrupt handlers leave interrupts
disabled on exit if pda.intr_mask was set. In which case, they would
bypass all work and we could never get preempted.
Yes, I was worried that if we left th
Matt Mackall wrote:
> I don't know that you need an xchg there. If you're still on the same
> CPU, it should all be nice and causal even across an interrupt handler.
> So it could be:
>
>pda.intr_mask = 0; /* intr_pending can't get set after this */
>
Why not? Oh, I see. intr_mask is inve
Matt Mackall wrote:
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get set after this */
Why not? Oh, I see. intr_mask is inverted for
Matt Mackall wrote:
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get set after this */
Why not? Oh, I see. intr_mask is inverted for
Jeremy Fitzhardinge wrote:
Yeah, disable interrupts, and set a flag that the fake "sti" can test, and
just return without doing anything.
(You may or may not also need to do extra work to Ack the hardware
interrupt etc, which may be irq-controller specific. Once the CPU has
accepted the inte
Jeremy Fitzhardinge wrote:
Yeah, disable interrupts, and set a flag that the fake "sti" can test, and
just return without doing anything.
(You may or may not also need to do extra work to Ack the hardware
interrupt etc, which may be irq-controller specific. Once the CPU has
accepted the inte
Jeremy Fitzhardinge wrote:
>> Yeah, disable interrupts, and set a flag that the fake "sti" can test, and
>> just return without doing anything.
>>
>> (You may or may not also need to do extra work to Ack the hardware
>> interrupt etc, which may be irq-controller specific. Once the CPU has
>> ac
Andi Kleen wrote:
One thing I was pondering was to replace the expensive popfs with
bt $IF,(%rsp)
jnc 1f
sti
1:
But would be mostly a P4 optimization again and I'm not 100% sure it is
worth it.
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but less important t
Andi Kleen wrote:
One thing I was pondering was to replace the expensive popfs with
bt $IF,(%rsp)
jnc 1f
sti
1:
But would be mostly a P4 optimization again and I'm not 100% sure it is
worth it.
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but less important t
Andi Kleen wrote:
> One thing I was pondering was to replace the expensive popfs with
>
> bt $IF,(%rsp)
> jnc 1f
> sti
> 1:
>
> But would be mostly a P4 optimization again and I'm not 100% sure it is
> worth it.
>
Worth it on 32-bit. On AMD64, probably not. On Intel 64-bit, maybe,
but le
Rusty Russell wrote:
> On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
>
>> On Mon, 19 Mar 2007, Eric W. Biederman wrote:
>>
>>> True. You can use all of the call clobbered registers.
>>>
>> Quite often, the biggest single win of inlining is not so much the code
>> size (a
Rusty Russell wrote:
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done righ
Rusty Russell wrote:
On Mon, 2007-03-19 at 11:38 -0700, Linus Torvalds wrote:
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done righ
Jeremy Fitzhardinge wrote:
> For example, say we wanted to put a general call for sti into entry.S,
> where its expected it won't touch any registers. In that case, we'd
> have a sequence like:
>
> push %eax
> push %ecx
> push %edx
> call paravirt_cli
> pop %edx
> pop %ecx
Jeremy Fitzhardinge wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
have a sequence like:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
Jeremy Fitzhardinge wrote:
For example, say we wanted to put a general call for sti into entry.S,
where its expected it won't touch any registers. In that case, we'd
have a sequence like:
push %eax
push %ecx
push %edx
call paravirt_cli
pop %edx
pop %ecx
pop %eax
Jeremy Fitzhardinge wrote:
> I think the suggestion is much simpler. If you convince gcc/binutils to
> leave the .reloc section in vmlinux, and make that available to the
> kernel itself, then you can scan all the kernel's relocs to find ones
> which refer to paravirt_ops, and use those to determi
Jeremy Fitzhardinge wrote:
I think the suggestion is much simpler. If you convince gcc/binutils to
leave the .reloc section in vmlinux, and make that available to the
kernel itself, then you can scan all the kernel's relocs to find ones
which refer to paravirt_ops, and use those to determine whi
Jeremy Fitzhardinge wrote:
Well, one thing to make clear is this is absolutely not a Xen-specific
patch or piece of code. This is part of the paravirt_ops infrastructure
designed to remove the overhead of all the indirect calls which are
scattered all over the place. (Perhaps I should post the
Jeremy Fitzhardinge wrote:
> Well, one thing to make clear is this is absolutely not a Xen-specific
> patch or piece of code. This is part of the paravirt_ops infrastructure
> designed to remove the overhead of all the indirect calls which are
> scattered all over the place. (Perhaps I should pos
Eric W. Biederman wrote:
> I'm not quite familiar with the context. And I'm to lazy to look right now.
> What is the difference with COMPAT_VDSO that it doesn't do relocation?
> What are we preserving?
>
COMPAT_VDSO causes the link address to be fixed at compile time to match
the virtual addr
Eric W. Biederman wrote:
I'm not quite familiar with the context. And I'm to lazy to look right now.
What is the difference with COMPAT_VDSO that it doesn't do relocation?
What are we preserving?
COMPAT_VDSO causes the link address to be fixed at compile time to match
the virtual address o
Jan Beulich wrote:
So I guess the right thing to do is relocate the dynamic stuff via
PT_DYNAMIC, and relocate the symtab if its present.
Symtab should also be deduced from program headers.
Learning more all the time..
I'm actually surprised this got re-implemented from scratch, whe
Jan Beulich wrote:
>> So I guess the right thing to do is relocate the dynamic stuff via
>> PT_DYNAMIC, and relocate the symtab if its present.
>>
>
> Symtab should also be deduced from program headers.
>
Learning more all the time..
> I'm actually surprised this got re-implemented from s
Jeremy Fitzhardinge wrote:
>
+} else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {
+Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+int tag;
+while ((tag = (++dyn)->d_tag) != DT_NULL)
Jeremy Fitzhardinge wrote:
+} else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {
+Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+int tag;
+while ((tag = (++dyn)->d_tag) != DT_NULL)
Um, no.
Walk based
X86_VOYAGER)
> help
> Paravirtualization is a way of running multiple instances of
>
Thanks Chris!
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
Sorry, I got exci
Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>
>> Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
>> by fixing up the ELF object.
>>
>>
>
> So does it actually work? Can you boot the broken distros with this in
> p
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
by fixing up the ELF object.
So does it actually work? Can you boot the broken distros with this in
place?
Well testing that is not so fun. I installed
when COMPAT_VDSO is enabled
by fixing up the ELF object.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.21/arch/i386/kernel/entry.S
===
--- linux-2.6.21.orig/arch/i386/kernel/entry.S 2007-03-06 18:51:33.00
when COMPAT_VDSO is enabled
by fixing up the ELF object.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Index: linux-2.6.21/arch/i386/kernel/entry.S
===
--- linux-2.6.21.orig/arch/i386/kernel/entry.S 2007-03-06 18:51:33.00
Pavel Machek wrote:
download & install alsalib
download & install alsautils
create 1007 nodes in /dev
I really hope you meant permission 1007 nodes, not 1007 nodes! I'm
checking right now, and if the latter is the case, I'm going to
uninstall alsa, even if that means
unction in order to override this weak
binding. This means the usual paravirt_ops technique of using an inline
function won't work in this case.
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
nted as a weak function in
> kernel/sched.c, we must define a real function in order to override this weak
> binding. This means the usual paravirt_ops technique of using an inline
> function won't work in this case.
>
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
Benjamin LaHaise wrote:
+/*
+ * We aggressively remove defunct pgd from cr3. We execute unmap_vmas()
+ * *much* faster this way.
+ */
Are you switching mms in order to avoid all of the overhead associated with
flushing an active mm during task exit? If so, it makes much more sense to
Benjamin LaHaise wrote:
>
>> +/*
>> + * We aggressively remove defunct pgd from cr3. We execute unmap_vmas()
>> + * *much* faster this way.
>> + */
>>
>
> Are you switching mms in order to avoid all of the overhead associated with
> flushing an active mm during task exit? If so, it makes
Andrew Morton wrote:
Really truly? I think we have a _lot_ of declarations which omit the section
qualifier altogether. How come they don't all break too?
User build was smoking this:
make O=build -j16
This and non-repeatable results make me suspect some kind of build
dependency proble
Andrew Morton wrote:
Really truly? I think we have a _lot_ of declarations which omit the section
qualifier altogether. How come they don't all break too?
According to the report I have. Perhaps a bogus section qualifier does
more damage than an omitted one. I'll get gcc / linker vers
Molle Bestefich wrote:
> In a virtualized environment running Xen or VMware, can the guest
> operating systems utilize hardware crypto acceleration such as the
> "PadLock" AES acceleration built into VIA CPUs?
VMware doesn't support VIA CPUs, and I think we would have compatibility
issues with th
Some gcc put this function in .init.text because the header didn't
match. For 2.6.21-rc.
Zach
Index: linux-2.6.21/include/asm-i386/vmi_time.h
===
--- linux-2.6.21.orig/include/asm-i386/vmi_time.h 2007-03-06
18:56:03.00
Ingo Molnar wrote:
makes sense. We can do Jan's relocatable-COMPAT_VDSO thing in v2.6.22,
but for v2.6.21 that's way too intrusive.
Agree. I think we can clean up some of the strange build magic though,
by adding boot time ELF magic instead. We'll see which works out better.
Zach
-
To u
Ingo Molnar wrote:
> makes sense. We can do Jan's relocatable-COMPAT_VDSO thing in v2.6.22,
> but for v2.6.21 that's way too intrusive.
>
Agree. I think we can clean up some of the strange build magic though,
by adding boot time ELF magic instead. We'll see which works out better.
Zach
___
Jeremy Fitzhardinge wrote:
> Is pte_offset_map allowed to happen within lazy mmu? I presume not,
> because you definitely don't want the mapping pte update to be deferred.
>
> Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
> I'm looking at kpte_clear_flush; I've already got
Zachary Amsden wrote:
VMI is broken under COMPAT_VDSO, as Xen and other non hardware
assisted hypervisors will be. I have been working on a fix for this
which works for older glibcs that panic when the new relocatable VDSO
is used. However, I believe at this time that the fix is going to be
Zachary Amsden wrote:
VMI is broken under COMPAT_VDSO, as Xen and other non hardware
assisted hypervisors will be. I have been working on a fix for this
which works for older glibcs that panic when the new relocatable VDSO
is used. However, I believe at this time that the fix is going to be
VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted
hypervisors will be. I have been working on a fix for this which works
for older glibcs that panic when the new relocatable VDSO is used.
However, I believe at this time that the fix is going to be too radical
to consider
VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted
hypervisors will be. I have been working on a fix for this which works
for older glibcs that panic when the new relocatable VDSO is used.
However, I believe at this time that the fix is going to be too radical
to consider
Jeremy Fitzhardinge wrote:
> Is pte_offset_map allowed to happen within lazy mmu? I presume not,
> because you definitely don't want the mapping pte update to be deferred.
>
> Or, more specifically, is kunmap_atomic ever allowed within lazy mmu?
> I'm looking at kpte_clear_flush; I've already got
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...] If that is the case then my ABI worries would indeed be wrong
and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach, som
Linus Torvalds wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
"For sure"? Absolutely not. But since any new interfaces we come up with
Jeremy Fitzhardinge wrote:
> No, but I'm not prejudiced against virtual hardware. If we have a piece
> of code that thinks its talking to an apic, then I think its OK to use
> that code whether its a real apic or a virtual one, _so long as its
> being used in a way that's consistent with its inten
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as its
being used in a way that's consistent with its intended in
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
[...] So it is a little late to tell us - "redesign your hypervisor,
or else.."
is this how long the "paravirt_ops hides all the details and the VMI
hypervisor ABI will never hinder Linux"
Andi Kleen wrote:
> At least in Linux we don't really work with deadlines; if there
> are issues they need to be fixed even if it takes longer. I don't
> expect the version in .21 to be really usable anyways; it is clearly
> still in development.
>
It was working, and I expect to have it wor
Andi Kleen wrote:
At least in Linux we don't really work with deadlines; if there
are issues they need to be fixed even if it takes longer. I don't
expect the version in .21 to be really usable anyways; it is clearly
still in development.
It was working, and I expect to have it working ag
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
Ingo, either you or Thomas have vetoed every attempt we have made to
make our code operate with clockevents. [...]
this is news to me - do you have any proof of such a veto?
Yes, your refusal to discuss any tec
Ingo Molnar wrote:
[...] And apparently the VMI version is the same, just with some short
cuts. Are you just worried about the ->apic_write() hooks or about
something else too?
i'm worried about those "shot cuts" (which in essence create software
variants of silicon), the hooks, the h
701 - 800 of 1203 matches
Mail list logo
