On Tuesday 18 December 2007 16:30:08 Avi Kivity wrote:
> Rusty Russell wrote:
> > Yes, I pondered this when I wrote the code. On the one hand, it's a
> > low-probability pathological corner case, on the other, your patch
> > reduces the number of timer reprograms in the normal case.
>
> One th
On Friday 14 December 2007 23:12:05 Christian Borntraeger wrote:
> Rusty, Anthony, Dor,
>
> I need your brain power :-)
>
> On smp guests I have seen a problem with virtio (the version in curent
> Avi's git) which do not occur on single processor guests:
>
> kernel BUG at /space/kvm/drivers/virtio/
On Friday 14 December 2007 05:30:31 Christian Borntraeger wrote:
> Rusty, if you decide to apply my patch, there is one downside: The
> debugging code in virtio_ring sometimes triggers with a false positive:
>
> try_fill_recv calls vring_kick. Here we do a notify to the host. This might
> cause an
Rusty Russell wrote:
On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote:
This patch changes the bitwise operations in bitops.h to get
a void pointers as a parameter. Before this patch, a lot of warnings
can be seen. They're gone after it.
No, this is a backwards step! These
Rusty Russell wrote:
On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
commit 763769621d271d92204ed27552d75448587c1ac0
Author: Dor Laor <[EMAIL PROTECTED]>
Date: Wed Dec 12 14:52:00 2007 +0200
[virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
transmit
The cur
On Tuesday 18 December 2007 09:52:36 Glauber de Oliveira Costa wrote:
> This patch changes the bitwise operations in bitops.h to get
> a void pointers as a parameter. Before this patch, a lot of warnings
> can be seen. They're gone after it.
No, this is a backwards step! These warnings are import
On Tuesday 18 December 2007 09:52:26 Glauber de Oliveira Costa wrote:
> +static inline int desc_empty(const void *ptr)
> +{
> + const u32 *desc = ptr;
> + return !(desc[0] | desc[1]);
> +}
Erk. This really needs to be a union, not a void *. I guess we can clean it
later.
Rusty.
This patch moves i387 definitions from processor_32.h and processor_64.h
to processor.h. They are different. Very different. And there's appearently
nothing we can do about it, so they're enclosed inside ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/proc
This patch moves the prefetch[w]? functions to processor.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 30 ++
include/asm-x86/processor_32.h | 25 -
include/asm-x86/processor_64.h |8
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.
Signed-off-by: Glauber de O
There's only one difference between the NOPs used in asm code for i386 and
x86_64:
i386 has a lot more variants. The code is moved to processor.h, and adjusted
accordingly.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 85
This patch moves the mm_segment_t structure definition to processor.h
This makes mmsegment.h file useless, and it is deleted.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/mmsegment.h |8
include/asm-x86/processor.h |5 +
include/a
current_text_addr() has a different implementation in x86_64 and
i386, but it is not fundamentally different. I stick to the i386
implementation, that seem to be a common base, and move it to processor.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h
There are currently two definitions of load_cr3, that essentially do the
same thing. This patch moves them all to processor.h.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/mmu_context_64.h |5 -
include/asm-x86/processor.h |7 +++
include/a
This patch removes definitions and macros that are not used anymore
from processor_64.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor_64.h | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
Index: linux-2.6-x86/include/asm-x86/pr
This patch moves the TASK_ALIGN constraints to common header.
The base of it is the same for x86_64 and i386. The only difference
is the presence of vSMP in x86_64. As it's not a worry in i386, we can
safely use the same code for both.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
-
Paravirt guests need to inform the underlying hypervisor whenever the sp0
tss field changes. i386 already has such a function, and we use it for
x86_64 too. There's an unnecessary (for 64-bit) msr handling part in the
original
version, and it is placed around an ifdef. Making no more sense in
proc
This patch changes the bitwise operations in bitops.h to get
a void pointers as a parameter. Before this patch, a lot of warnings
can be seen. They're gone after it.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/bitops.h | 39 --
This patch moves definitions that are present in only one of the files
(between processor_32.h and processor_64.h), to processor.h. They're mostly
structures and function definitions.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |2 +-
arch/x
This patch moves the pieces of processor_32.h and processor_64 that are
equal to processor.h. Only what's exactly the same is moved around, the rest
not being touched.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 116 ++
x86_cpuinfo is one more to the family of "not fundamentally different"
structs. It's unified in processor.h, with very specific fields enclosed
around ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |6 +-
include/asm-x86/processor.h
The thread_struct is not fundamentally different between architectures, and
this patch puts it in the common header. What's really unique for each of
them is enclosed in ifdefs.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h| 44
This patch moves the definition of set_iopl_mask to processor.h,
instead of letting it at processor_32.h.
For x86_64, nothing is done, as we don't really need such a function.
However, having it on both arches saves us from putting an ifdef in the
pv_cpu_ops struct.
Signed-off-by: Glauber de Olive
Although slighly different, the tss_struct is very similar in x86_64 and
i386. The really different part, which matchs the hardware vision of it, is
now called x86_hw_tss, and each of the architectures provides yours.
It's then used as a field in the outter tss_struct.
Signed-off-by: Glauber de Ol
This patch unifies the paravirt pieces of processor.h
The functionality present in 32 bit, but not (yet) in 64-bit,
like load_sp0 is _not_ done here, and let to a different patch.
With this unification, we get paravirt for free in x86_64 processor.h
Signed-off-by: Glauber de Oliveira Costa <[EMAI
There's no need for the *_MASK flags (TF_MASK, IF_MASK, etc), found in
processor.h (both _32 and _64). They have a one-to-one mapping with the
EFLAGS value. This patch removes the definitions, and use the already
exisant X86_EFLAGS_ version when applicable.
Signed-off-by: Glauber de Oliveira Costa
This patch moves the (duplicated) desc_empty implementation to desc.h,
where the descriptor things belong.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/desc.h |6 ++
include/asm-x86/processor_32.h |6 --
include/asm-x86/processor_64.h |
Hi,
This series integrate the processor.h header. There are a lot of things
that are deeply architectural differences between architectures, but
I've done my best to come to a settlement.
With this series, I am very close to have selectable paravirt for x86_64,
It applies ontop of today's x86 gi
This patch wipes out the definitions of tsc_disable from processor_32.h
and move it to tsc.h, were it belongs
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/processor_32.h |7 ---
include/asm-x86/tsc.h |6 ++
2 files changed, 6 insertion
On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
> commit 763769621d271d92204ed27552d75448587c1ac0
> Author: Dor Laor <[EMAIL PROTECTED]>
> Date: Wed Dec 12 14:52:00 2007 +0200
>
> [virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
> transmit
>
> The current start_xm
On Saturday, 15 of December 2007, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > Linux never uses that register. The only user is suspend
> > > save/restore, but that' bogus because it wasn't ever initialized by
> > > Linux in the first place. It could be probably all
> It probably is safe to remove... but we currently support '2.8.95
> kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses
> cr8.
No it won't. 2.8 would just restore some random useless value.
If 2.8 wants to use CR8 it would have to re-initialize it
-Andi
_
On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, Ingo Molnar wrote:
> >
> > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > > > Linux never uses that register. The only user is suspend
> > > > save/restore, but that' bogus because it wasn't ever initiali
On Monday, 17 of December 2007, Pavel Machek wrote:
> On Mon 2007-12-17 01:27:29, Rafael J. Wysocki wrote:
> > On Saturday, 15 of December 2007, Ingo Molnar wrote:
> > >
> > > * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > >
> > > > > Linux never uses that register. The only user is suspend
> > >
On Sat 2007-12-15 14:26:38, Andi Kleen wrote:
> > It probably is safe to remove... but we currently support '2.8.95
> > kernel loads/resumes 2.6.24 image'... which would break if 2.8 uses
> > cr8.
>
> No it won't. 2.8 would just restore some random useless value.
Restoring random value seems wron
On Tue 2007-12-04 20:34:32, Andi Kleen wrote:
> On Tue, Dec 04, 2007 at 09:18:33PM +0200, Avi Kivity wrote:
> > Glauber de Oliveira Costa wrote:
> >> This patch moves the i386 control registers manipulation functions,
> >> wbinvd, and clts functions to system.h. They are essentially the same
> >> a
36 matches
Mail list logo
