Steven Rostedt wrote:
> --
> On Thu, 9 Aug 2007, Andi Kleen wrote:
>
>>> This has to match the normal C calling convention though, doesn't it?
>>>
>> Native cli/sti/save/restore_flags are all only assembly and can be easily
>> (in fact more easily than in C) written as pure assembler
--
On Thu, 9 Aug 2007, Andi Kleen wrote:
>
> > This has to match the normal C calling convention though, doesn't it?
>
> Native cli/sti/save/restore_flags are all only assembly and can be easily
> (in fact more easily than in C) written as pure assembler functions. Then
> you can use whatever
> Hm. So x86-64 doesn't make 64-bit pointers be 64-bit aligned?
The ABI does of course, although the penalty of not doing it on current
CPUs is only minor.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
> This has to match the normal C calling convention though, doesn't it?
Native cli/sti/save/restore_flags are all only assembly and can be easily
(in fact more easily than in C) written as pure assembler functions. Then
you can use whatever calling convention you want.
While some paravirt
--
On Thu, 9 Aug 2007, Jeremy Fitzhardinge wrote:
> Glauber de Oliveira Costa wrote:
> > On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> >>> Does it really matter?
> >>>
> >>>
> >> Well, yes, if alignment is an issue.
> >>
> > Of course, But the question rises from the context
Glauber de Oliveira Costa wrote:
> On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>>> Does it really matter?
>>>
>>>
>> Well, yes, if alignment is an issue.
>>
> Of course, But the question rises from the context that they are both
> together at the beginning. So they
On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> > Does it really matter?
> >
>
> Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together at the beginning. So they are not making anybody non-aligned.
Then the question: Why
Glauber de Oliveira Costa wrote:
>>> +/*
>>> + * integers must be use with care here. They can break the
>>> PARAVIRT_PATCH(x)
>>> + * macro, that divides the offset in the structure by 8, to get a number
>>> + * associated with the hook. Dividing by four would be a solution, but it
>>> + * would
> > + case PARAVIRT_PATCH(make_pgd):
> > + case PARAVIRT_PATCH(pgd_val):
> > + case PARAVIRT_PATCH(make_pte):
> > + case PARAVIRT_PATCH(pte_val):
> > + case PARAVIRT_PATCH(make_pmd):
> > + case PARAVIRT_PATCH(pmd_val):
> > + case PARAVIRT_PATCH(make_pud):
> > + case
Andi Kleen wrote:
>> +if (opfunc == NULL)
>> +/* If there's no function, patch it with a ud2a (BUG) */
>> +ret = paravirt_patch_insns(site, len, start_ud2a, end_ud2a);
>>
>
> This will actually give corrupted BUGs because you don't supply
> the full inline BUG
Glauber de Oliveira Costa wrote:
> +static unsigned native_patch(u8 type, u16 clobbers, void *insns, unsigned
> len)
> +{
> + const unsigned char *start, *end;
> + unsigned ret;
> +
> + switch(type) {
> +#define SITE(x) case PARAVIRT_PATCH(x): start = start_##x; end =
> end_##x;
Andi Kleen wrote:
+if (opfunc == NULL)
+/* If there's no function, patch it with a ud2a (BUG) */
+ret = paravirt_patch_insns(site, len, start_ud2a, end_ud2a);
This will actually give corrupted BUGs because you don't supply
the full inline BUG header. Perhaps
Glauber de Oliveira Costa wrote:
+static unsigned native_patch(u8 type, u16 clobbers, void *insns, unsigned
len)
+{
+ const unsigned char *start, *end;
+ unsigned ret;
+
+ switch(type) {
+#define SITE(x) case PARAVIRT_PATCH(x): start = start_##x; end =
end_##x; goto
+ case PARAVIRT_PATCH(make_pgd):
+ case PARAVIRT_PATCH(pgd_val):
+ case PARAVIRT_PATCH(make_pte):
+ case PARAVIRT_PATCH(pte_val):
+ case PARAVIRT_PATCH(make_pmd):
+ case PARAVIRT_PATCH(pmd_val):
+ case PARAVIRT_PATCH(make_pud):
+ case
Glauber de Oliveira Costa wrote:
+/*
+ * integers must be use with care here. They can break the
PARAVIRT_PATCH(x)
+ * macro, that divides the offset in the structure by 8, to get a number
+ * associated with the hook. Dividing by four would be a solution, but it
+ * would limit the future
On 8/9/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Does it really matter?
Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together at the beginning. So they are not making anybody non-aligned.
Then the question: Why would
Glauber de Oliveira Costa wrote:
On 8/9/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Does it really matter?
Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together at the beginning. So they are not making
--
On Thu, 9 Aug 2007, Jeremy Fitzhardinge wrote:
Glauber de Oliveira Costa wrote:
On 8/9/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Does it really matter?
Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together
--
On Thu, 9 Aug 2007, Andi Kleen wrote:
This has to match the normal C calling convention though, doesn't it?
Native cli/sti/save/restore_flags are all only assembly and can be easily
(in fact more easily than in C) written as pure assembler functions. Then
you can use whatever calling
This has to match the normal C calling convention though, doesn't it?
Native cli/sti/save/restore_flags are all only assembly and can be easily
(in fact more easily than in C) written as pure assembler functions. Then
you can use whatever calling convention you want.
While some paravirt
Hm. So x86-64 doesn't make 64-bit pointers be 64-bit aligned?
The ABI does of course, although the penalty of not doing it on current
CPUs is only minor.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
Steven Rostedt wrote:
--
On Thu, 9 Aug 2007, Andi Kleen wrote:
This has to match the normal C calling convention though, doesn't it?
Native cli/sti/save/restore_flags are all only assembly and can be easily
(in fact more easily than in C) written as pure assembler functions. Then
Rusty Russell wrote:
> On Thu, 2007-08-09 at 02:24 +0200, Andi Kleen wrote:
>
>> Not sure what's best. Ok using a normal export is easiest and not
>> that big an issue.
>>
>
> Yeah, there's also been talk of breaking up paravirt_ops into multiple
> structs by area, which would lead
On Thu, 2007-08-09 at 02:24 +0200, Andi Kleen wrote:
> Not sure what's best. Ok using a normal export is easiest and not
> that big an issue.
Yeah, there's also been talk of breaking up paravirt_ops into multiple
structs by area, which would lead naturally into finer-grained export
control.
On Thursday 09 August 2007 01:18:57 Rusty Russell wrote:
> On Wed, 2007-08-08 at 11:49 -0300, Glauber de Oliveira Costa wrote:
> > On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > +EXPORT_SYMBOL(paravirt_ops);
> > >
> > > Definitely _GPL at least.
> > Sure.
>
> We ended up making it
On Wed, 2007-08-08 at 11:49 -0300, Glauber de Oliveira Costa wrote:
> On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > +EXPORT_SYMBOL(paravirt_ops);
> >
> > Definitely _GPL at least.
> Sure.
We ended up making it EXPORT_SYMBOL in i386 because every driver wants
to save and restore interrupt
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Is this really synced with the latest version of the i386 code?
Roasted already commented on this. I will check out and change it here.
>
> > +#ifdef CONFIG_PARAVIRT
> > +#include
> > +#endif
>
>
> > +#include
> > +#include
> > +#include
>
On Wed, 8 Aug 2007, Andi Kleen wrote:
> Strictly you would at least need a !X86_VSMP dependency, but
> with the vsmp change i requested that will be unnecessary
>
> Is this really synced with the latest version of the i386 code?
Glauber started the paravirt ops 64 a second time around, from
> +config PARAVIRT
> + bool "Paravirtualization support (EXPERIMENTAL)"
This should be hidden and selected by the clients as needed
(I already did this change on i386)
Users know nothing about paravirt, they just know about Xen, lguest
etc.
Strictly you would at least need a !X86_VSMP
+config PARAVIRT
+ bool Paravirtualization support (EXPERIMENTAL)
This should be hidden and selected by the clients as needed
(I already did this change on i386)
Users know nothing about paravirt, they just know about Xen, lguest
etc.
Strictly you would at least need a !X86_VSMP
On Wed, 8 Aug 2007, Andi Kleen wrote:
Strictly you would at least need a !X86_VSMP dependency, but
with the vsmp change i requested that will be unnecessary
Is this really synced with the latest version of the i386 code?
Glauber started the paravirt ops 64 a second time around, from scratch
On 8/8/07, Andi Kleen [EMAIL PROTECTED] wrote:
Is this really synced with the latest version of the i386 code?
Roasted already commented on this. I will check out and change it here.
+#ifdef CONFIG_PARAVIRT
+#include asm/paravirt.h
+#endif
+#include linux/errno.h
+#include
On Wed, 2007-08-08 at 11:49 -0300, Glauber de Oliveira Costa wrote:
On 8/8/07, Andi Kleen [EMAIL PROTECTED] wrote:
+EXPORT_SYMBOL(paravirt_ops);
Definitely _GPL at least.
Sure.
We ended up making it EXPORT_SYMBOL in i386 because every driver wants
to save and restore interrupt state.
On Thursday 09 August 2007 01:18:57 Rusty Russell wrote:
On Wed, 2007-08-08 at 11:49 -0300, Glauber de Oliveira Costa wrote:
On 8/8/07, Andi Kleen [EMAIL PROTECTED] wrote:
+EXPORT_SYMBOL(paravirt_ops);
Definitely _GPL at least.
Sure.
We ended up making it EXPORT_SYMBOL in i386
On Thu, 2007-08-09 at 02:24 +0200, Andi Kleen wrote:
Not sure what's best. Ok using a normal export is easiest and not
that big an issue.
Yeah, there's also been talk of breaking up paravirt_ops into multiple
structs by area, which would lead naturally into finer-grained export
control.
Rusty Russell wrote:
On Thu, 2007-08-09 at 02:24 +0200, Andi Kleen wrote:
Not sure what's best. Ok using a normal export is easiest and not
that big an issue.
Yeah, there's also been talk of breaking up paravirt_ops into multiple
structs by area, which would lead naturally into
36 matches
Mail list logo
