> I am not quite clear about the purpose of pv-ops , what do we want to
> deal with by developping "pv-ops"? is it used for HVM or for PV or KVM
> or something ? I have seen it for a few months in the list ,and
> "pv-ops"is an active project ,but i am not clear about what is the aim
> of "pv-ops" ,
On Tuesday 04 December 2007 11:41, Glauber de Oliveira Costa wrote:
> On Dec 4, 2007 5:18 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > There is no cr8 register on i386. This had better be protected by an
> > #ifdef.
>
> Sure. I mentioned it in the changelog. I, however, am not sure If I
> agree i
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
>> as in x86_64, except for the cr8 register, which we add.
On Tue, Dec 04, 2007 at 09:09:57AM -0200, Glauber de Oliveira Costa wrote:
> This patch turns the sched_clock into native_sched_clock.
> sched clock becomes a weak symbol, which can then give its
> place to a paravirt definition.
I ended up regretting that solution on i386, it would be better
to s
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> There's really nothing new here.
>
> No changes at all, just fixing errors raised by checkpatch, at ingo's
> request.
thanks, i picked them up.
Ingo
___
Virtualization mailing list
Vir
Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, 2007-12-04 at 13:01 +0100, Gerd Hoffmann wrote:
>
Who uses the gntdev device right now?
>>> Good question! I'm aware of it being used in a few research projects,
>>> and it seems to work for them (though I think it is mostly used with the
>>> linux
On Dec 4, 2007 5:18 PM, Avi Kivity <[EMAIL PROTECTED]> 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
> > as in x86_64, except for the cr8 register, which we
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
as in x86_64, except for the cr8 register, which we add.
+
+static inline unsigned long native_read_cr8(void)
+{
+ unsi
This patche changes the native_write_msr() and friends interface
to explicitly take 2 32-bit registers instead of a 64-bit value.
The change will ease the merge with 64-bit code. As the 64-bit
value will be passed as two registers anyway in i386,
the PVOP_CALL interface has to account for that and
This patch moves the switch_to() macro to system.h
As those macros are fundamentally different between i386 and x86_64,
they are enclosed around an ifdef.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/system.h| 61 +
Mr. Grep says warn_if_not_ulong() is not used anymore anywhere
in the code. So, we remove it.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/system_64.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/asm-x86/system_64.h b/includ
This patch finishes the unification of system.h file.
i386 needs a constant to be defined, and it is defined inside an ifdef
Other than that, pretty much nothing but includes are left in the arch
specific headers, and they are deleted.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
The memory barrier parts of system.h are not very different between
i386 and x86_64, the main difference being the availability of
instructions, which we handle with the use of ifdefs.
They are consolidated in system.h file, and then removed from
the arch-specific headers.
Signed-off-by: Glauber
the p parameter is an explicit memory reference, and is
enough to prevent gcc to being nasty here. The volatile
seems completely not needed.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/system_32.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
di
This patch moves the i386 control registers manipulation functions,
wbinvd, and clts functions to system.h. They are essentially the same
as in x86_64, except for the cr8 register, which we add.
With this, system.h paravirt comes for free in x86_64.
Signed-off-by: Glauber de Oliveira Costa <[EMAI
This patch puts together pieces of system_{32,64}.h that
looks like the same. It's the first step towards integration
of this file.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/process_64.c |2 +-
include/asm-x86/system.h | 70
This patch unifies the load_segment() macro, making them equal in both
x86_64 and i386 architectures. The common version goes to system.h,
and the old are deleted.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/system.h| 21 +
include/as
This patch uses the _ASM_ALIGN and _ASM_PTR macros
to make the fixups in native_read/write_msr_safe look the same
for x86_64 and i386. Besides using this macros, we also have to
take the explicit instruction suffixes out. It's okay
because all this instructions uses registers, and can be sized by
t
the rdpmc instruction gets a counter argument in rcx. However,
the i386 version was ignoring it. To make both x86_64 and i386 versions
the same, as well as to comply with the instruction semantics, this
parameter is added in the i386 version
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECT
This patches proceeds with the integration of msr.h, making
the code unified, instead of having a version for each architecture.
We stick with the native_* functions, and then paravirt comes for free.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 161 ++
Hi,
In the same lines of the msr.h integration, here it goes a series for
system.h. Again, after the headers are turned into one, the paravirt
pieces related to system.h comes for free.
___
Virtualization mailing list
Virtualization@lists.linux-founda
Targetting paravirt, this patch introduces native_read_tscp, in
place of rdtscp() macro. When in a paravirt guest, this will
involve a function call, and thus, cannot be done in the vdso area.
These users then have to call the native version directly
Signed-off-by: Glauber de Oliveira Costa <[EMAI
This patch splits get_cycles_sync() into __get_cycles_sync(),
and the rdtscll part. Paravirt guests cannot issue rdtscl directly,
as it involves a function call in vdso area.
So, using the __get_cycles_sync() base, we introduce vget_cycles_sync,
which then calls the native version of rdtscll. Ide
cpuid is not very different between i386 and x86_64.
We move away the x86_64 version from msr.h, and
unify them at processor.h, where they belong.
cpuid() paravirt then comes for free.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 67
Among other things, using -traditional as a gcc option stops us from
using macro token pasting, which is a feature we heavily rely on.
There was still a use of -traditional in arch/x86/kernel/Makefile_64,
which this patch removes.
I don't see any problems building kernels in my x86_64 box without
This patch turns the sched_clock into native_sched_clock.
sched clock becomes a weak symbol, which can then give its
place to a paravirt definition.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/tsc_64.c | 15 ++-
1 files changed, 14 insertions(+),
The functions under #ifdef CONFIG_SMP in msr.h are the same
for both x86_64 and i386, and this patches removes one of them,
putting them in a single location
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 33 +++--
1 files ch
There's really nothing new here.
No changes at all, just fixing errors raised by checkpatch, at ingo's
request.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar escreveu:
> * Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>>
>> This series of patches integrates msr.h header. What it really does,
>> is a series of steps to allow us to get rid of duplicate code between
>> i386 an
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This series of patches integrates msr.h header. What it really does,
> is a series of steps to allow us to get rid of duplicate code between
> i386 and x86_64 versions
>
> With this done, achieving paravirt for x86_64 gets re
Among other things, using -traditional as a gcc option stops us from
using macro token pasting, which is a feature we heavily rely on.
There was still a use of -traditional in arch/x86/kernel/Makefile_64,
which this patch removes.
I don't see any problems building kernels in my x86_64 box without
This patch splits get_cycles_sync() into __get_cycles_sync(),
and the rdtscll part. Paravirt guests cannot issue rdtscl directly,
as it involves a function call in vdso area.
So, using the __get_cycles_sync() base, we introduce vget_cycles_sync,
which then calls the native version of rdtscll. Ide
This patches proceeds with the integration of msr.h, making
the code unified, instead of having a version for each architecture.
We stick with the native_* functions, and then paravirt comes for free.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 161 ++
the rdpmc instruction gets a counter argument in rcx. However,
the i386 version was ignoring it. To make both x86_64 and i386 versions
the same, as well as to comply with the instruction semantics, this
parameter is added in the i386 version
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECT
This patch uses the _ASM_ALIGN and _ASM_PTR macros
to make the fixups in native_read/write_msr_safe look the same
for x86_64 and i386. Besides using this macros, we also have to
take the explicit instruction suffixes out. It's okay
because all this instructions uses registers, and can be sized by
t
Hello,
This series of patches integrates msr.h header.
What it really does, is a series of steps to allow us
to get rid of duplicate code between i386 and x86_64 versions
With this done, achieving paravirt for x86_64 gets really easy,
just a couple of extra code.
The first patch was already sent
This patche changes the native_write_msr() and friends interface
to explicitly take 2 32-bit registers instead of a 64-bit value.
The change will ease the merge with 64-bit code. As the 64-bit
value will be passed as two registers anyway in i386,
the PVOP_CALL interface has to account for that and
The functions under #ifdef CONFIG_SMP in msr.h are the same
for both x86_64 and i386, and this patches removes one of them,
putting them in a single location
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 33 +++--
1 files ch
Targetting paravirt, this patch introduces native_read_tscp, in
place of rdtscp() macro. When in a paravirt guest, this will
involve a function call, and thus, cannot be done in the vdso area.
These users then have to call the native version directly
Signed-off-by: Glauber de Oliveira Costa <[EMAI
This patch turns the sched_clock into native_sched_clock.
sched clock becomes a weak symbol, which can then give its
place to a paravirt definition.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/tsc_64.c | 15 ++-
1 files changed, 14 insertions(+),
cpuid is not very different between i386 and x86_64.
We move away the x86_64 version from msr.h, and
unify them at processor.h, where they belong.
cpuid() paravirt then comes for free.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h | 67
Hi,
On Tue, 2007-12-04 at 13:01 +0100, Gerd Hoffmann wrote:
> >> Who uses the gntdev device right now?
> >
> > Good question! I'm aware of it being used in a few research projects,
> > and it seems to work for them (though I think it is mostly used with the
> > linux-2.6.18-xen kernel). Anyone e
Derek Murray wrote:
> Gerd Hoffmann wrote:
>> Oh, for me it isn't robust at all, it crashes on the first munmap
>> syscall. It is the Fedora 8 kernel. See attachment. Didn't try
>> xensource 2.6.18 yet.
>
> My gut feeling is that something changed in mm between 2.6.18 and
> 2.6.21, but that see
Gerd Hoffmann wrote:
On this point I completely agree with you! If anyone has any less
radical suggestions, then I'd be delighted to refactor the gntdev code
to use them. However, I'm not currently aware of any alternative that
maintains robustness to process crashes.
Oh, for me it isn't robust
44 matches
Mail list logo
