Guys currently I am horrified by the ease at which I can find
bugs in the pending paravirtualization patches. I have barely
even looked at arch/i386 in the -mm tree and it feels like
I am tripping over significant bugs left and right.
Because no one has heeded my advice and put in a proper platf
On Fri, Apr 27, 2007 at 04:27:21PM -0700, Jeremy Fitzhardinge wrote:
> Herbert Xu wrote:
> > They can be applied separately so you don't need the dom0 part for your
> > tree.
>
> Great, thanks.
BTW, the version I posted to you is missing the following line.
Cheers,
--
Visit Openswan at http://w
We don't actually need the Guest handlers mapped to avoid double
fault, just the stack pages. Thanks to Zach for confirming.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drivers/lguest/interrupts_and_traps.c | 26 +-
drivers/lguest/lg.h |2
Herbert Xu wrote:
> They can be applied separately so you don't need the dom0 part for your
> tree.
Great, thanks.
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtua
On Fri, Apr 27, 2007 at 03:19:50PM -0700, Jeremy Fitzhardinge wrote:
>
> OK, I've been sitting on this in the hope that I'll suddenly see the
> light and work out what you're talking about - but apparently that's not
> going to happen. So, some questions:
>
>1. Does this patch change the dom
Herbert Xu wrote:
> Sure thing. I'll look over it soon.
>
> Actually there is one thing I'd like to see changed first up: I noticed
> that you've stripped out the checksum hack which is in the main Xen tree.
> We actually have the code in net-2.6.22 (which is also in mm) that lets
> you use CHECKS
On Friday 27 April 2007 08:46:19 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> >> +/* VCPUs are single-cored, and have no siblings */
> >> +static void set_cpu_sibling_map(int cpu)
> >>
> >
> > Can you put this somewhere generic and use it everywhere? Don't want
> > duplication of this code
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
