On 27/4/07 08:08, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
>> Don't you need a rmb() here then? The CPU could speculate reads
>> (more occurrences)
>>
>
> Is rmb() sufficient? It will stop a speculative read on the pending
> flag, but will it make sure the write has happened by then?
Andi Kleen wrote:
>> +/* convert from IF type flag */
>> +flags = !(flags & X86_EFLAGS_IF);
>> +vcpu = x86_read_percpu(xen_vcpu);
>> +vcpu->evtchn_upcall_mask = flags;
>> +if (flags == 0) {
>> +barrier(); /* unmask then check (avoid races) */
>>
>
> Don't you ne
Andi Kleen wrote:
> The major problem was that it didn't compile on x86-64.
>
Ah, OK. I don't think you mentioned that. I'll fix that up.
> And a few uglities in there
>
Such as?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
> > To summarize the outstanding issues are:
> > - fixing sched_clock first
> >
>
> What was the sched_clock problem? I don't remember and outstanding
> issues with it. I noticed you didn't take paravirt-sched_clock.
The major problem was that it didn't compile on x86-64.
And a few uglities
Andi Kleen wrote:
> For me you don't need anymore, but possibly for others.
>
Hm. I'm not a fan of the great big monolithic patch myself, but on the
other hand I don't like the idea of patches which are not self-contained
steps from working->working state. Xen-core.patch is currently the
(mor
> To summarize the outstanding issues are:
> - fixing sched_clock first
> - hopefully more review of the core pieces by others
> - what i commented (minor stuff mostly)
> - review of xenbus and drivers
> [i did upto the grant table code, but not more]
- and more testing by other people (forgot t
On Wednesday 25 April 2007 21:41:23 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> >> ... will review the rest later.
> >>
> >
> > Rest is ok
> >
>
> Thanks for looking at it. I'll try to separate xen-core into more
> digestable pieces.
For me you don't need anymore, but possibly for o
Andi Kleen wrote:
>> ... will review the rest later.
>>
>
> Rest is ok
>
Thanks for looking at it. I'll try to separate xen-core into more
digestable pieces.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
> ... will review the rest later.
Rest is ok
-Andi
-
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andi Kleen wrote:
> On Monday 23 April 2007 23:56:44 Jeremy Fitzhardinge wrote:
>
>> Core Xen Implementation
>>
>> This patch is a rollup of all the core pieces of the Xen
>> implementation, including booting, memory management, interrupts, time
>> and so on.
>>
>
> The patch is definitely
On Monday 23 April 2007 23:56:44 Jeremy Fitzhardinge wrote:
> Core Xen Implementation
>
> This patch is a rollup of all the core pieces of the Xen
> implementation, including booting, memory management, interrupts, time
> and so on.
The patch is definitely too big.
> +#ifdef CONFIG_XEN
> +/* Xen
11 matches
Mail list logo
