This set of patches builds the infrastructure to do both passthrough and
intercept based virtualization of TSC in KVM.
Unfortunately, I got caught up on the mechanics of the locking for quite
some time to this work is a bit delayed, and the tail end of the patches
is in a bit of a messy state, whe
On 12/14/2009 01:22 AM, Joerg Roedel wrote:
The tsc_offset adjustment in svm_vcpu_load is executed
unconditionally even if Linux considers the host tsc as
stable. This causes a Linux guest detecting an unstable tsc
in any case.
This patch removes the tsc_offset adjustment if the host tsc
is stabl
With current upstream changes, VMX operation now relies on have the
user-notifiers infrastructure. This makes kvm-kmod use on older kernels
untenable.
I looked a bit at fixing the underlying problem by simulating the
user-return callback when we context switch, but it is uglier than I
would
Define cpufreq_get for kernels which don't export it when not config'd.
Signed-off-by: Zachary Amsden
diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h
index 47fdc86..6fe7d87 100644
--- a/external-module-compat-comm.h
+++ b/external-module-compat-comm.h
If cpufreq can't determine the CPU khz, or cpufreq is not compiled in,
we should fallback to the measured TSC khz.
Signed-off-by: Zachary Amsden
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 11a6f2f..6604f4c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1
Even if not using cpufreq, there is little justification for exporting
cpufreq_quick_get and not cpufreq_get, especially when it is so easy
and harmless to do.
Signed-off-by: Zachary Amsden
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 44717eb..684fc4b 100644
--- a
On 10/09/2009 10:47 AM, Jan Kiszka wrote:
Zachary Amsden wrote:
On 10/09/2009 10:36 AM, Jan Kiszka wrote:
Zachary Amsden wrote:
On 10/08/2009 01:18 PM, Jan Kiszka wrote:
Zachary Amsden wrote:
They are globals, not clearly protected by any ordering
On 10/09/2009 10:36 AM, Jan Kiszka wrote:
Zachary Amsden wrote:
On 10/08/2009 01:18 PM, Jan Kiszka wrote:
Zachary Amsden wrote:
They are globals, not clearly protected by any ordering or locking, and
vulnerable to various startup races.
Instead, for variable TSC machines
On 10/08/2009 01:18 PM, Jan Kiszka wrote:
Zachary Amsden wrote:
They are globals, not clearly protected by any ordering or locking, and
vulnerable to various startup races.
Instead, for variable TSC machines, register the cpufreq notifier and get
the TSC frequency directly from the cpufreq
Patch is self-explanatory
commit 071a800cd07c2b9d13c7909aa99016d89a814ae6
Author: Zachary Amsden
Date: Wed Sep 30 17:03:16 2009 -1000
Remove warning due to kvm_mmu_notifier_change_pte being static
Signed-off-by: Zachary Amsden
diff --git a/sync b/sync
index b09f629..0bbd488
On 09/30/2009 06:11 AM, Avi Kivity wrote:
On 09/30/2009 06:06 PM, Zachary Amsden wrote:
On 09/30/2009 05:56 AM, Avi Kivity wrote:
On 09/30/2009 05:51 PM, Zachary Amsden wrote:
If the API allows us to query the tsc frequency, it would simply
return the same values in all cases, which we&#
On 09/30/2009 05:56 AM, Avi Kivity wrote:
On 09/30/2009 05:51 PM, Zachary Amsden wrote:
If the API allows us to query the tsc frequency, it would simply
return the same values in all cases, which we'd ignore.
The API only allows querying the processor frequency. In the
constant_tsc
On 09/29/2009 10:45 PM, Avi Kivity wrote:
On 09/29/2009 11:38 PM, Zachary Amsden wrote:
Signed-off-by: Zachary Amsden
Looks good.
Is anything preventing us from unifying the constant_tsc and !same
paths? We could just do a quick check in the notifier, see the tsc
frequency hasn't ch
Both VMX and SVM require per-cpu memory allocation, which is done at module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online could not be hardware enabled.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |4
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9a4daca..d1036ce 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -330,13 +330,14 @@ static int
efore running on a VCPU.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 15d2ace..de4ce8f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3116,9 +3116,22
On 09/28/2009 10:30 PM, Avi Kivity wrote:
On 09/29/2009 06:04 AM, Zachary Amsden wrote:
Both VMX and SVM require per-cpu memory allocation, which is done at
module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9a4daca..d1036ce 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -330,13 +330,14 @@ static int
Both VMX and SVM require per-cpu memory allocation, which is done at module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online could not be hardware enabled.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |4
efore running on a VCPU.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 30 --
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 15d2ace..9cbd53a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3116,9 +3116,22
Greatly simplified version of the patches; allocate and dealloc
all required structs at module load and unload time.
Clarification: per_cpu(var, cpu) does indeed work for not-present CPUs;
the allocations for module specific per-cpu variables are done at module
load and unload time, while the
On 09/26/2009 10:54 PM, Avi Kivity wrote:
First, I'm not sure per_cpu works for possible but not actual cpus.
Second, we now eagerly allocate but lazily free, leading to lots of
ifs and buts. I think the code can be cleaner by eagerly allocating
and eagerly freeing.
Eager freeing requires
On 09/26/2009 10:52 PM, Avi Kivity wrote:
On 09/25/2009 03:47 AM, Zachary Amsden wrote:
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1716,9 +1716,6 @@ static int kvm_cpu_hotplug(struct
notifier_block *notifier, unsigned long val,
{
int cpu = (long)v;
-if
CPU frequency change callback provides new TSC frequency for us, and in the
same units (kHz), so there is no reason to do any math.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm
bringup TSC rate will be, so the
guess of using tsc_khz could be wrong). So, we clear the rate to zero in such
a case and add logic to query it upon entry.
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/svm.c | 15 +--
arch/x86/kvm
.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |2 +-
arch/x86/kvm/vmx.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 8f99d0c..13ca268 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -525,7 +525,7
, as no error prone measurement
is required. On such machines, also detect the frequency when bringing
a new CPU online; it isn't clear what frequency it will start with, and
it may not correspond to the reference.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c |
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3116,9 +3116,22
Simplified the patch series a bit and fixed some bugs noticed by Marcelo.
Axed the hot-remove notifier (was not needed), fixed a locking bug by
using cpufreq_quick_get, fixed another bug in kvm_cpu_hotplug that was
filtering out online notifications when KVM was loaded but not in use.
--
To unsubs
On 09/24/2009 05:52 AM, Marcelo Tosatti wrote:
+static __cpuinit int vmx_cpu_hotadd(int cpu)
+{
+ struct vmcs *vmcs;
+
+ if (per_cpu(vmxarea, cpu))
+ return 0;
+
+ vmcs = alloc_vmcs_cpu(cpu);
+ if (!vmcs)
+ return -ENOMEM;
+
+ per_cpu(vm
, as no error prone measurement
is required. On such machines, also detect the frequency when bringing
a new CPU online; it isn't clear what frequency it will start with, and
it may not correspond to the reference.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c |
CPU frequency change callback provides new TSC frequency for us, and in the
same units (kHz), so there is no reason to do any math.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm
For the non-hotplug case, this TSC speed should be available; instead, clear
cpu_khz_tsc when bringing down a CPU so it is recomputed at the next bringup.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a
bringup TSC rate will be, so the
guess of using tsc_khz could be wrong). So, we clear the rate to zero in such
a case and add logic to query it upon entry.
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm/kvm_host.h |2 ++
arch/x86/kvm/svm.c | 15 +--
arch/x86/kvm
In the process of bringing down CPUs, the SVM / VMX structures associated
with those CPUs are not freed. This may cause leaks when unloading and
reloading the KVM module, as only the structures associated with online
CPUs are cleaned up.
Signed-off-by: Zachary Amsden
---
arch/x86/include/asm
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3116,9 +3116,22
Patch speaks for itself.
commit b5cd58bc3e7bddf0a9735d5c13c36e2221a7f616
Author: Zachary Amsden
Date: Fri Aug 21 14:34:37 2009 -1000
Make vma_kernel_pagesize a kvm compat API; this fixes the build with
new kernels synced to 2.6.31 compiling externally for older systems.
Signed
Zachary Amsden wrote:
> | 24H 100M 82V >
> You pierce the beastly fido's heart, you heartbreaker you...
> The beastly fido is dead!
> You receive 8 experience points.
> Your blood freezes as you hear the beastly fido's death cry.
>
> | 24H 100M 82V >
&g
Avi Kivity wrote:
> I disagree, I think requiring multiple sessions for controlling a single
> application is clumsy. I can't think of one protocol which uses it. I
> don't think IMAP requires multiple sessions (and I don't think commands
> from one session can affect the other, except through t
Anthony Liguori wrote:
> However, I do like the idea though of QEMU queuing events for a certain
> period of time. Not everyone always has something connected to a
> monitor. I may notice that my NFS server (which runs in a VM) is not
> responding, VNC to the system, switch to the monitor, and t
On Fri, 2008-10-03 at 16:45 -0700, Yinghai Lu wrote:
> On Fri, Oct 3, 2008 at 3:58 PM, Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-10-03 at 15:51 -0700, Yinghai Lu wrote:
> >
> >> ok, my question is: anyone tried to use kexec with vmware?
> >
>
On Fri, 2008-10-03 at 15:51 -0700, Yinghai Lu wrote:
> ok, my question is: anyone tried to use kexec with vmware?
Do you mean has anyone tried to use kexec in Linux running under VMware,
or do you mean has anyone tried to use kexec to start ESX?
My answers: yes, and I would hope not.
Zach
___
On Fri, 2008-10-03 at 14:58 -0700, Yinghai Lu wrote:
> On Fri, Oct 3, 2008 at 2:48 PM, Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-10-03 at 14:40 -0700, Yinghai Lu wrote:
> >> On Fri, Oct 3, 2008 at 2:21 PM, Zachary Amsden <[EMAIL PROTECTED]> wrote:
&
On Fri, 2008-10-03 at 14:40 -0700, Yinghai Lu wrote:
> On Fri, Oct 3, 2008 at 2:21 PM, Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-10-03 at 14:08 -0700, Yinghai Lu wrote:
> >> anyone tried to use linux kernel to kexec vmware esx?
> >
> > That woul
On Fri, 2008-10-03 at 14:08 -0700, Yinghai Lu wrote:
> anyone tried to use linux kernel to kexec vmware esx?
That would not be a recommended practice. It might work. It should not
be very useful.
Zach
___
kexec mailing list
kexec@lists.infradead.org
On Wed, 2008-10-01 at 17:39 -0700, H. Peter Anvin wrote:
> third, which is subject to spread-spectrum modulation due to RFI
> concerns. Therefore, relying on the *nominal* frequency of this clock
I'm not suggesting using the nominal value. I'm suggesting the
measurement be done in the one and on
On Wed, 2008-10-01 at 17:39 -0700, H. Peter Anvin wrote:
> third, which is subject to spread-spectrum modulation due to RFI
> concerns. Therefore, relying on the *nominal* frequency of this clock
I'm not suggesting using the nominal value. I'm suggesting the
measurement be done in the one and on
On Wed, 2008-10-01 at 14:34 -0700, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Alok Kataria wrote:
> >
> > I guess, but the bulk of the uses of this stuff are going to be
> > hypervisor-specific. You're hard-pressed to come up with any other
> > generic uses beyond tsc.
>
> And arguab
On Wed, 2008-10-01 at 14:34 -0700, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Alok Kataria wrote:
> >
> > I guess, but the bulk of the uses of this stuff are going to be
> > hypervisor-specific. You're hard-pressed to come up with any other
> > generic uses beyond tsc.
>
> And arguab
On Tue, 2008-07-15 at 12:22 -0700, Yinghai Lu wrote:
> On Tue, Jul 15, 2008 at 11:51 AM, Suresh Siddha
> <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 15, 2008 at 11:38:50AM -0700, Zachary Amsden wrote:
> >>
> >> Nacked-by: Zachary Amsden <[EMAIL PROTECTED]>
On Tue, 2008-07-15 at 12:10 -0700, Yinghai Lu wrote:
> On Tue, Jul 15, 2008 at 12:04 PM, Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-07-15 at 11:51 -0700, Suresh Siddha wrote:
> >> On Tue, Jul 15, 2008 at 11:38:50AM -0700, Zachary Amsden wrote:
> >
On Tue, 2008-07-15 at 11:51 -0700, Suresh Siddha wrote:
> On Tue, Jul 15, 2008 at 11:38:50AM -0700, Zachary Amsden wrote:
> >
> > Nacked-by: Zachary Amsden <[EMAIL PROTECTED]>
> >
> > What are you doing here and why aren't you cc-ing the maintainers?
>
&
On Tue, 2008-07-15 at 11:52 -0700, Yinghai Lu wrote:
> > Nacked-by: Zachary Amsden <[EMAIL PROTECTED]>
>
> because of not ccing you?
Because it's wrong.
> >
> > What are you doing here and why aren't you cc-ing the maintainers?
>
> did you che
mi_apic_icr_write,
> >> +.wait_icr_idle = vmi_apic_wait_icr_idle,
> >> +.safe_wait_icr_idle = vmi_safe_apic_wait_icr_idle,
> >> +};
> >> +#endif
> >> +
> >> /*
> >> * VMI setup common to all processors
> >> */
On Sat, 2008-05-31 at 01:13 +0100, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > We don't fault. We write directly to the primary page tables, and clear
> > the pte just like native. We just issue all mprotect updates in the
> > queue, and flush the queue
On Fri, 2008-05-23 at 21:32 +0100, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > I'm a bit skeptical you can get such a semantic to work without a very
> > heavyweight method in the hypervisor. How do you guarantee no other CPU
> > is fizzling the A/D bits in
On Fri, 2008-05-23 at 15:20 +0100, Jeremy Fitzhardinge wrote:
> Hi all,
>
> This little series adds a new transaction-like abstraction for doing
> RMW updates to a pte, hooks it into paravirt_ops, and then makes use
> of it in Xen.
>
> The basic problem is that mprotect is very slow under Xen (u
On Tue, 2008-05-06 at 15:46 -0400, Rik van Riel wrote:
> On Tue, 06 May 2008 17:33:02 +0200
> Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-03-13 at 16:57 +, Hugh Dickins wrote:
> > > It's very encouraging to see Jeremy and Rusty weighing in. I hope
> > > Zach will too, and I
On Fri, 2008-03-14 at 11:30 -0700, Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
> > How about a fake hypervisor, which is really just a random page evictor,
> > following the rules of CMM?
> >
>
> Probably simpler to just have variants of the page_set_* func
On Thu, 2008-03-13 at 20:45 +0100, Andrea Arcangeli wrote:
> On Thu, Mar 13, 2008 at 10:45:07AM -0700, Zachary Amsden wrote:
> > What doesn't appear to be useful however, is support for this under
> > VMware. It can be done, even without the writable pte support (yes,
> &g
On Thu, 2008-03-13 at 18:55 +, Hugh Dickins wrote:
> On Thu, 13 Mar 2008, Jeremy Fitzhardinge wrote:
> >
> > My other concern is just correctness over time on the Linux side. We
> > already
> > have enough trouble keeping things like the pte and page structure state in
> > sync, with result
On Thu, 2008-03-13 at 16:57 +, Hugh Dickins wrote:
> Oh, that would be such a shame. Your guest page hinting patches remind
> me of that childhood thrill, when once a year the circus comes to town ;)
I like the circus too.
> But seriously, I'm ashamed to see my name in the Cc list: it would
On Tue, 2008-02-05 at 13:44 +0700, Igor M Podlesny wrote:
> On 2008-02-05 13:34, Arjan van de Ven wrote:
> [...]
> >>1) To have compiled it I had to replace global_flush_tlb()
> >> call with __flush_tlb_all() and still guessing was it(?) a correct
> >> replacment at all :-)
> >
> > it is not;
; 32-bit or 64-bit guest kernel?
> >
> > 32-bit.
> >
> > Yep, this fixed the problem.
>
> great! I've added:
>
>Tested-by: Jeff Chua <[EMAIL PROTECTED]>
>
> to the commit message as well, if you dont mind. Full patch is below.
Acke
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > The first fix is not even specific for PARAVIRT, and it's actually
> > > preventing the whole tree from booting.
> >
> > on CONFIG_EFI, indeed :)
>
> but in exchange you broke all of 32-bit
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > The first fix is not even specific for PARAVIRT, and it's actually
> > > preventing the whole tree from booting.
> >
> > on CONFIG_EFI, indeed :)
>
> but in exchange you broke all of 32-bit
ks boxes got upgraded so I
can't test, but install base is really big.
Acked-by: Zachary Amsden <[EMAIL PROTECTED]>
--
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.or
On Fri, 2008-01-11 at 18:08 +, Alan Cox wrote:
> This lets us remove port 0x80 use on the PCI systems. It also speeds
> up
> some of the later 8390 based cores where we know the device does not
> need
> delay loops either because it has internal handling or in most cases a
> faster device anywa
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
> Zachary Amsden wrote:
> >
> > According to Phoenix Technologies book "System BIOS for IBM PCs,
> > Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
> >
> > port 0080h
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > BTW, it isn't ever safe to pass port 0x80 through to hardware from a
> > virtual machine; some OSes use port 0x80 as a hardware available scratch
> > register (I believe Darw
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> On 09-01-08 06:30, Christer Weinigel wrote:
> I'd not expect very time crtical. The current outb_p use gives a delay
> somewhere between .5 and 2 microseconds as per earlier survey meaning a
> udelay(1) or 2 would be enough -- again, at the
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> Alan Cox wrote:
> > The natsemi docs here say otherwise. I trust them not you.
> >
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they s
On Mon, 2007-11-26 at 14:06 -0800, Yinghai Lu wrote:
> >> diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/smpboot_64.c
> >> index 500670c..966d124 100644
> >> --- a/arch/x86/kernel/smpboot_64.c
> >> +++ b/arch/x86/kernel/smpboot_64.c
> >> @@ -912,7 +912,7 @@ void __init smp_prepare_cpu
On Mon, 2007-11-26 at 00:38 -0800, Yinghai Lu wrote:
> [PATCH] x86_64: not set boot cpu in cpu_online_map at smp_prepare_boot_cpu
>
> in init/main.c boot_cpu_init() does that before
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/kernel/smpboot_64.c b/arch/x86/kernel/
On Wed, 2007-11-21 at 02:25 -0800, Roland McGrath wrote:
> This consolidates the four different places that implemented the same
> encoding magic for the GDT-slot 32-bit TLS support. The old tls32.c is
> renamed and only slightly modified to be the shared implementation guts.
> -#define GET_BASE(
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file for
On Wed, 2007-11-21 at 02:20 -0800, Roland McGrath wrote:
> This changes a couple of places to use the get_desc_base function.
> They were duplicating the same calculation with different equivalent code.
>
> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
>
> diff --git a/arch/x86/ia32/tls32.c b
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file for
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file for
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This makes x86_64's ia32 emulation support share the sources used in the
> 32-bit kernel for the 32-bit vDSO and much of its setup code.
>
> The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
> The abi.syscall32 sy
On Mon, 2007-11-19 at 14:06 -0800, Roland McGrath wrote:
> This changes the 64-bit kernel's support for the 32-bit sysenter
> instruction to use stored fields rather than constants for the
> user-mode return address, as the 32-bit kernel does. This adds a
> sysenter_return field to struct thread_i
On Fri, 2007-11-16 at 11:24 -0800, Jeremy Fitzhardinge wrote:
> Do you use paravirt_alloc_pd_clone()? I seem to you remember you
> mentioning that it doesn't help you very much. I'm in the process of
> unifying pgalloc*, and it seems to me that it would be a bit cleaner
> without needing to worry
On Tue, 2007-11-13 at 22:22 +, 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 wh
On Tue, 2007-11-13 at 08:18 -0500, Gregory Haskins wrote:
> Since PCI was designed as a hardware solution it has all kinds of stuff
> specifically geared towards hardware constraints. Those constraints
> are different in a virtualized platform, so some things do not translate
> well to an optima
On Tue, 2007-11-13 at 08:18 -0500, Gregory Haskins wrote:
> Since PCI was designed as a hardware solution it has all kinds of stuff
> specifically geared towards hardware constraints. Those constraints
> are different in a virtualized platform, so some things do not translate
> well to an optima
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
On Tue, 2007-10-30 at 10:02 -0200, Glauber de Oliveira Costa wrote:
> > No, if no paravirt clocksource is detected, nothing can override the
> > perfect TSC hardware clocksource rating of 400. And if a paravirt
> > clocksource is detected, it is always better than TSC.
>
> Why always? tsc is the
On Tue, 2007-10-30 at 10:02 -0200, Glauber de Oliveira Costa wrote:
> > No, if no paravirt clocksource is detected, nothing can override the
> > perfect TSC hardware clocksource rating of 400. And if a paravirt
> > clocksource is detected, it is always better than TSC.
>
> Why always? tsc is the
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > Not every guest support paravirt, but for correctness, all guests
> > require TSC, which must be exposed all the way up to userspace, no
> > matter what the ef
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > Not every guest support paravirt, but for correctness, all guests
> > require TSC, which must be exposed all the way up to userspace, no
> > matter what the ef
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> if it's inaccurate why are you exposing it to the guest then? Native
> only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but fo
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> if it's inaccurate why are you exposing it to the guest then? Native
> only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but fo
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> tsc is very good time source (when it does not have drifts, does not
> change it's frequency, i.e. when it works), so it should have its rating
> raised to a value greater
On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> tsc is very good time source (when it does not have drifts, does not
> change it's frequency, i.e. when it works), so it should have its rating
> raised to a value greater
On Thu, 2007-10-25 at 16:57 -0700, Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > The conditional add/sub using carry trick is not generally bogus.
> > But for registers it's a fine optimization.
>
> For registers it's fine. For memory, it's a disaster. It's more than
401 - 500 of 1203 matches
Mail list logo
