up in all emulators
and virtual machines tested, including Xen, VMware, Virtual PC, and Qemu.
It is also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
Ind
Stefan Richter wrote:
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
Maintainers are apparently those under "PARAVIRT_OPS INTERFACE".
CCs added.
index c12720d..e3ce5c8 100644
--- a/arch
Chris Wright wrote:
* Stefan Richter ([EMAIL PROTECTED]) wrote:
-#ifdef CONFIG_DEBUG_PAGE_TYPE
+#if 0 /* debug page type */
This misnamed CONFIG_DEBUG_PAGE_TYPE (it's not a Kconfig variable) has
about 120 lines debug code dangling on it. So, replacing it by #if 0
will hopefully
Jeremy Fitzhardinge wrote:
I never merged the whole bit upstream because it added a field to
struct page.
Hm, is that a big problem? It would be OK for a debug config option,
wouldn't it? Also, it doesn't seem particularly vmi-specific. Could
it be made part of the pvops infrastructure?
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
I though about it, but it gets really ugly. You need wrappers for
all the MMU ops in pvops generic code, which means either another
layer of wrappers or a bunch of CONFIG_DEBUG_PARAVIRT
Oh, yes, more wrappers please! We could do it at the
Rusty Russell wrote:
The main effect is to change the definition of "struct desc_struct" to
a union of more complex types.
Yay! Someone finally killed it. Every time I tried to kill it, I ended
up off in the weeds chasing some bug.
diff -r 656f3ff2c9ce arch/i386/kernel/process.c
@@ -
Martin Schwidefsky wrote:
From: Martin Schwidefsky <[EMAIL PROTECTED]>
Nobody is using ptep_test_and_clear_dirty and ptep_clear_flush_dirty.
Remove the functions from all architectures.
-static inline int
-ptep_test_and_clear_dirty (struct vm_area_struct *vma, unsigned long addr,
pte_t *ptep)
Andrew Morton wrote:
Presumably someone is getting a lot of these messages.
Do we know why? Is there something which needs fixing here?
I got it a lot when using any sort of virtualization on my Core2Duo
(kvm, vmware, qemu). Just a big spew. Honestly, I was getting this with
2.6.20, a
Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
When we're about two weeks away from a product release and you are
threatening to unmerge or block our code because we didn't create an
abstract interrupt controller, we re-used the APIC and IO-APIC, this
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
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:
* 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"
Thomas Gleixner wrote:
On Thu, 2007-03-08 at 02:06 -0800, Zachary Amsden wrote:
The correct solution here is to properly separate the APIC, SMP, and
timer code so the logic of it which we want to reuse is separated from
the hardware dependence. Clock events and clocksources take care of
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
We faithfully emulate lapic, io_apic, the pit, pic, and a normal
interrupt subsystem.
Can you not just use the apic clock driver directly then? Do you need
to do anything special?
The apic clock driver is going to program the apic
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
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
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
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
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
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
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
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
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
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
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
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
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
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
H. Peter Anvin wrote:
Zachary Amsden wrote:
Some PTE optimizations for native and paravirt-ops kernels; this
provides a huge win for shadow mode hypervisors and gets rid of
some unnecessary atomic instructions in native kernels, saving
even more on UP by getting rid of implicit LOCK on xchg
Hugh Dickins wrote:
Zach, while looking at your recent patches, I ran across the comment
on pte_update_defer, and where it was being used, and now think that
David's patch is actually incorrect. Previously pte_update_defer
was being used where a flush_tlb_page followed immediately after
within t
Hugh Dickins wrote:
Zach, while looking at your recent patches, I ran across the comment
on pte_update_defer, and where it was being used, and now think that
David's patch is actually incorrect. Previously pte_update_defer
was being used where a flush_tlb_page followed immediately after
within t
Jeremy Fitzhardinge wrote:
It seems to me that the problem is simply that it runs out of space.
head.S maps 8Mbytes of memory. The kernel takes ~6.8M of that, and
there simply isn't enough remaining space to fit the pagetables to map
all memory into the kernel address space. Here's my dump of
Hugh Dickins wrote:
David (clear_refs_pte_range) is only using ptep_test_and_clear_young,
though he did change the ptep_test_and_clear_dirty definition to be
consistent with it. old/young is never so serious as clean/dirty, so
it may be that there's very little problem with what's in there now;
H. Peter Anvin wrote:
#ifdef CONFIG_X86_PAE
PAGE_TABLE_SIZE = (2048+4)*4096
#else
PAGE_TABLE_SIZE = (1024+1)*4096
#endif
BOOTMEM_SIZE = 128*1024
/* ACPI and SMP trampoline allocate bootmem pages before paging_init */
#ifdef CONFIG_SMP
SMP_BOOTMEM_EARLY= 1
#else
SMP_BOOTMEM_EARLY= 0
#endif
#if
H. Peter Anvin wrote:
+ /*
+* End condition: we must map up to and including
+* INIT_MAP_BEYOND_END bytes beyond the end of our
+* own page tables; 0x1000 is the size of the page
+* table were about to write, and +0x007 is the
+* attribute bits.
+
H. Peter Anvin wrote:
Zachary Amsden wrote:
H. Peter Anvin wrote:
+/*
+ * End condition: we must map up to and including
+ * INIT_MAP_BEYOND_END bytes beyond the end of our
+ * own page tables; 0x1000 is the size of the page
+ * table were about to write, and +0x007 is the
Hugh Dickins wrote:
You're right to want to defer your pte_updates, David is right to want
to batch his TLB flushes. It bothers me that you have a surprising case,
and that unless you abandon your optimization, it imposes a new constraint
on how to proceed in common code (without #ifdef'ing arou
David Rientjes wrote:
Sure, but what I really like about the patch is that we're only flushing
something if !flush_end in the first place. So we can eliminate any TLB
flushing if that VMA didn't need it; that's a change from the current
behavior. And since the most obvious use-case for /proc/
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
In shadow mode hypervisors, ptep_get_and_clear achieves the desired
purpose of keeping the shadows in sync by issuing a native_get_and_clear,
followed by a call to pte_update, which indicates the PTE has been
modified.
Direct mode hypervisors
Eric W. Biederman wrote:
I don't even want to think about how a kernel module gets far enough
into the kernel to be affected by our vector layout. These are internal
implementation details, without anything exported to modules.
Can I please see the source of the code in vmware that is doing thi
Eric W. Biederman wrote:
Is this linux running on vmware or vmware running on linux?
VMware running on Linux.
This sounds like playing with fire. Although I suppose you could do it
generally
by making software irqs trigger a general protection fault.
Better if you don't have to; th
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
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
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
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
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:
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:
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
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
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
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
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:
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
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:
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
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
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
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
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
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
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&
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:
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:
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:
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:
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:
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
.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
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
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
Remove a warning about unused variable in !CONFIG_ACPI compilation.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 1969f6c3440a arch/i386/kernel/acpi/earlyquirk.c
--- a/arch/i386/kernel/acpi/earlyquirk.cFri Apr 06 14:27:45 2007 -0700
+++ b/arch/i386/kernel/acpi/earlyq
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/
Now that the VDSO can be relocated, we can support it in VMI configurations.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 158d9ffb46fe arch/i386/Kconfig
--- a/arch/i386/Kconfig Thu Mar 29 04:17:05 2007 -0700
+++ b/arch/i386/Kconfig Thu Mar 29 04:18:05 2007 -0700
@@ -220,7
-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 14:25:03 2007 -0700
@@ -69,6 +69,7 @@ static struct {
void (*flush_tlb)(int);
Copying of the pgd range must happen under the pgd_lock. This got broken by
the paravirt changes in the -mm tree. Badness can result if you copy the pgd
before being added to the list when splitting or rejoining large pages.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
d
IRQ. It actually
gets delivered by the APIC hardware, but we don't want to use the same local
APIC clocksource processing, so we create our own handler here.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r c02ab981c99c arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makef
fixing the potential race.
Subject: Fix BusLogic to stop using check_region
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 15645892b508 drivers/scsi/BusLogic.c
--- a/drivers/scsi/BusLogic.c Mon Apr 09 13:43:06 2007 -0700
+++ b/drivers/scsi/BusLogic.c Mon Apr 09 14:52:00 2007
stray warnings around for no good reason.
Also, when possible, it is better to use block scoped variables
because gcc can sometime generate better code.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r ed741f57dae8 arch/i386/kernel/cpu/mcheck/p4.c
--- a/arch/i386/kernel/cpu/mcheck/p
Chris Wright wrote:
Thanks for the review! Comments inline.
+/* paravirt_ops.get_wallclock = vmi_get_wallclock */
Style nit, these pv_ops.foo = vmi_foo style comments aren't really useful.
Yeah, and easy to get out of sync. I'll drop them.
+ .rating = 1000,
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
+void __init vmi_time_init(void)
+{
+ /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */
+ outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */
That shouldn't be necessary using clocke
Jeremy Fitzhardinge wrote:
Why not submit a patch to do what you need here? (The Geode comment is
a bit worrying though.)
Why should VMI add workaround into PIT code? PIT code wants to know
nothing about VMI. It understands PIT timers on hardware. VMI, on the
other hand, is special - i
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Yes, but unfortunately that is a nop:
/*
* Avoid unnecessary state transitions, as it confuses
* Geode / Cyrix based boxen.
*/
case CLOCK_EVT_MODE_SHUTDOWN:
if (evt
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
+void __init vmi_time_init(void)
+{
+ /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */
+ outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */
That shouldn't be necessary using clocke
Some PTE optimizations for native and paravirt-ops kernels; this
provides a huge win for shadow mode hypervisors and gets rid of
some unnecessary atomic instructions in native kernels, saving
even more on UP by getting rid of implicit LOCK on xchg instruction.
Zach
-
To unsubscribe from this list:
.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r c02c6f5e882c arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Wed Apr 11 16:25:09 2007 -0700
+++ b/arch/i386/kernel/paravirt.c Wed Apr 11 17:09:55 2007 -0700
@@ -315,8 +315,6 @@ struct paravirt_ops paravi
d-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 1478ce4ec9e3 include/asm-i386/pgtable-2level.h
--- a/include/asm-i386/pgtable-2level.h Wed Apr 11 17:13:10 2007 -0700
+++ b/include/asm-i386/pgtable-2level.h Wed Apr 11 18:22:51 2007 -0700
@@ -35,6 +35,11 @@ static inline void native_se
Add comment and condense code to make use of native_local_ptep_get_and_clear
function. Also, it turns out the 2-level and 3-level paging definitions
were identical, so move the common definition into pgtable.h
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r b3bbc1b5e085 inclu
optimization for non-SMP kernels; drop the atomic
xchg operations from page table updates.
Thanks to Michel Lespinasse for noting this potential optimization.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 47495b2532b3 include/asm-i386/pgtable-2level.h
--- a/include/asm-i386/p
Dave Jones wrote:
On Wed, Apr 11, 2007 at 10:30:58PM -0700, Zachary Amsden wrote:
> In situations where page table updates need only be made locally, and there
> is no cross-processor A/D bit races involved, we need not use the heavyweight
> xchg instruction to atomically fetch and c
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
In shadow mode hypervisors, ptep_get_and_clear achieves the desired
purpose of keeping the shadows in sync by issuing a native_get_and_clear,
followed by a call to pte_update, which indicates the PTE has been
modified.
Direct mode hypervisors
Eric W. Biederman wrote:
I suspect what we want to do is come up with a function to call
to test to see if a page should be read-only and map such pages
_PAGE_KERNEL_RO, or _PAGE_KERNEL_RO_EXEC if it's code.
Speaking of things what are paravirt_alloc_pd and parafirt_alloc_pd
supposed to do?
Andrew Morton wrote:
On Thu, 01 Mar 2007 03:34:18 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
Why is it a bug? Because there's a deadlock where this CPU is waiting for
CPU A to take the IPI, but CPU A is waiting (with interrupts disabled) for
this CPU to take an IPI.
Andrew Morton wrote:
The handler for smp_call_function() is called with local interrupts
disabled (from the IPI handler).
So to provide a consistent call environment for that handler, on_each_cpu()
will also disable local interrupts when making the direct call on this CPU.
Similarly the !CONFIG
Rusty Russell <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
---
include/asm-i386/paravirt.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
===
--- a/include/asm-i386/paravirt.h
+++ b/include/a
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Fix a few clobbers to include the return register. The clobbers set
is the set of all registers modified (or may be modified) by the code
snippet, regardless of whether it was deliberate or accidental.
Signed
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Things like what? Do you mean the %[foo] asm parameter syntax? I think
those versions are no longer supported - Arjan posted a patch a few days
ago to convert a pile of asms to this form. Or do you mean something
else?
I meant
201 - 300 of 371 matches
Mail list logo
