Jeremy Fitzhardinge escreveu:
Glauber de Oliveira Costa wrote:
Thanks for the explanation, Andi. I understand it much better now, and
agree with you.
As alternatives what we have now, we can either keep the paravirt_ops
as it is now for the native case, just hooking the vsmp functions in
place
Glauber de Oliveira Costa wrote:
> Thanks for the explanation, Andi. I understand it much better now, and
> agree with you.
>
> As alternatives what we have now, we can either keep the paravirt_ops
> as it is now for the native case, just hooking the vsmp functions in
> place of the normal one, (th
> between __cacheline_aligned_in_smp and other compile time bits based on
> VSMP specific INTERNODE_CACHE, etc. I think compile time the way to go.
Yes you're right they'll need an additional build option for that.
It would be too wasteful to have the big cache line for all paravirt kernels.
But i
On 8/15/07, Chris Wright <[EMAIL PROTECTED]> wrote:
> * Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> > Only caveat, is that it has to be done before smp gets in the game, and
> > with interrupts disabled. (which makes the function in vsmp.c not eligible).
> >
> > My current option is to f
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> Only caveat, is that it has to be done before smp gets in the game, and
> with interrupts disabled. (which makes the function in vsmp.c not eligible).
>
> My current option is to force VSMP to use PARAVIRT, as said before, and
> then fill
Chris Wright escreveu:
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
As alternatives what we have now, we can either keep the paravirt_ops as
it is now for the native case, just hooking the vsmp functions in place
of the normal one, (there are just three ops anyway), refill the
paravi
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> As alternatives what we have now, we can either keep the paravirt_ops as
> it is now for the native case, just hooking the vsmp functions in place
> of the normal one, (there are just three ops anyway), refill the
> paravirt_ops entirely i
> Maybe we could even make VSMP depend on PARAVIRT, to make it sure it is
> completely a paravirt client.
That's the right thing to do I think. Remove the existing ifdefs
and hook vsmp in only using paravirt ops.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Andi Kleen escreveu:
On Wed, Aug 15, 2007 at 12:09:42PM -0300, Glauber de Oliveira Costa wrote:
Again, this is the code of such function:
static inline int raw_irqs_disabled_flags(unsigned long flags)
{
return !(flags & X86_EFLAGS_IF);
}
so all it is doing is getting a parameter (flags)
On Wed, Aug 15, 2007 at 12:09:42PM -0300, Glauber de Oliveira Costa wrote:
> Again, this is the code of such function:
>
> static inline int raw_irqs_disabled_flags(unsigned long flags)
> {
> return !(flags & X86_EFLAGS_IF);
> }
> so all it is doing is getting a parameter (flags), and bitm
Avi Kivity escreveu:
Glauber de Oliveira Costa wrote:
Andi Kleen escreveu:
On Wed, Aug 15, 2007 at 11:18:25AM -0300, Glauber de Oliveira Costa
wrote:
Didn't we agree this should be a pvops client?
-Andi
No. I exposed my reasoning, asked you back, but got no answer.
I'll do it again:
This o
Glauber de Oliveira Costa wrote:
Andi Kleen escreveu:
On Wed, Aug 15, 2007 at 11:18:25AM -0300, Glauber de Oliveira Costa
wrote:
Didn't we agree this should be a pvops client?
-Andi
No. I exposed my reasoning, asked you back, but got no answer.
I'll do it again:
This operations are just man
Andi Kleen escreveu:
On Wed, Aug 15, 2007 at 11:18:25AM -0300, Glauber de Oliveira Costa wrote:
Didn't we agree this should be a pvops client?
-Andi
No. I exposed my reasoning, asked you back, but got no answer.
I'll do it again:
This operations are just manipulating bits, and are doing no
p
On Wed, Aug 15, 2007 at 11:18:25AM -0300, Glauber de Oliveira Costa wrote:
> > Didn't we agree this should be a pvops client?
> >
> > -Andi
> >
> No. I exposed my reasoning, asked you back, but got no answer.
> I'll do it again:
>
> This operations are just manipulating bits, and are doing no
> pr
> Didn't we agree this should be a pvops client?
>
> -Andi
>
No. I exposed my reasoning, asked you back, but got no answer.
I'll do it again:
This operations are just manipulating bits, and are doing no
privileged operations at all. Nothing that can be paravirtualized, in
the proper sense. Altough
> +#ifdef CONFIG_X86_VSMP
> +static inline int raw_irqs_disabled_flags(unsigned long flags)
> +{
> + return !(flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC);
> +}
> +
> +#else
> static inline int raw_irqs_disabled_flags(unsigned long flags)
> {
> return !(flags & X86_EFLAGS_IF);
> }
This patch turns the irq_flags and halt routines into the
native versions.
[ updates from v1
Move raw_irqs_disabled_flags outside of the PARAVIRT ifdef to
avoid increasing the mess, suggested by Andi Kleen
]
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Signed-off-by: Steven Rosted
17 matches
Mail list logo
