[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110727165844.GA8064@dumpdata.com>
Date: Wed, 27 Jul 2011 12:58:45 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Andrew Lutomirski <luto@....edu>
Cc: jeremy@...p.org, xen-devel@...ts.xensource.com, x86@...nel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
virtualization@...ts.linux-foundation.org, keir.xen@...il.com
Subject: Re: [Xen-devel] Re: [PATCH 0/5] Collected vdso/vsyscall fixes for 3.1
> >> $ test_vsyscall test
> >> Testing gettimeofday...
> >> vDSO offset = 0.000001s
> >> vsyscall offset = 0.000001s
> >>
> >> Testing time...
> >> vDSO offset = 0
> >> vsyscall offset = 0
> >> Testing getcpu...
> >> ok! cpu=6 node=0
> I bet if you pull a new copy or remove -mavx from Makefile it will
> work. I got a grossly hacked-up Xen domU booted and everything seems
> to work.
It did. Both Dom0 and DomU work on AMD and Intel.
In regards to the last pv-ops patch - is there no better way? The reason I am asking
is the pv-ops hook is just a bandaid for the problem. Is the Xen syscall suppose to
be doingsomething extra with the stack perhaps?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists