>>> On 04.08.14 at 16:07, wrote:
> On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
>> >>> On 15.07.14 at 16:59, wrote:
>> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
>> >> Adding xen-devel and some of the Linux
>>> On 15.07.14 at 16:59, wrote:
> On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
>> Adding xen-devel and some of the Linux maints,
>>
>> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
>> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
>> >
>> > Ther
>>> On 06.12.12 at 09:34, Ian Campbell wrote:
> (trim quote please...)
> On Wed, 2012-12-05 at 21:47 +, Konrad Rzeszutek Wilk wrote:
>> Do you want to prep a patch that I can stick in my 'microcode' branch?
>> .. That I will at some point try to upstream.
>
> You might want to look back at th
>>> On 05.12.12 at 17:48, Boris Ostrovsky wrote:
> On 12/05/2012 07:43 AM, Ian Campbell wrote:
>> I've just tried this on a fam 15h and I get:
>>
>> (XEN) microcode: collect_cpu_info: patch_id=0x6000626
>> (XEN) microcode: size 5260, block size 2592, offset 60
>> (XEN) m
>>> On 26.11.12 at 14:21, Ian Campbell wrote:
> Debian has decided to take Jeremy's microcode patch [0] as an interim
> measure for their next release. (TL;DR -- Debian is shipping pvops Linux
> 3.2 and Xen 4.1 in the next release. See http://bugs.debian.org/693053
> and https://lists.debian.org/
>>> On 09.11.12 at 10:05, wrote:
Since it looks like this got stalled again, attached is a slightly
extended version of Keir's debugging patch, allowing to rule out
any inconsistencies of the globals between the first and second
instances of the two invocations of __read_platform_stime().
Should
>>> On 09.11.12 at 10:05, wrote:
> oops, excuse me, here is a description : I have the problem on 4 systems,
> all with same hardware.
> the problem occured on each system, 1 time each 2 month in average. since
> January 2012, I decided to reboot them all monthly,
> and the clock jump occurred
>>> On 08.11.12 at 11:38, Keir Fraser wrote:
> On 08/11/2012 09:39, "Jan Beulich" wrote:
>
>>>>>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>>>>>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>
>>> On 07.11.12 at 18:40, Keir Fraser wrote:
> On 07/11/2012 13:22, "Ian Campbell" wrote:
>
(XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
tsc_st
>>> On 07.11.12 at 11:10, wrote:
> i compiled a patched hypervisor for Mauro, it is running since many days
> and the overflow occured,
> without clock jumps
>
>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>> plt_st
>>> Andrea Arcangeli 06/07/12 12:35 PM >>>
>Oops, sorry I didn't imagine atomic64_read on a pmd would trip.
The problem really is that the cmpxchg8b is a write, and hence won't go
through without faulting on a write protected page (which all page table
pages necessarily are).
>I guess if Xen can
>>> On 11.10.11 at 10:02, Ian Campbell wrote:
> On Tue, 2011-10-11 at 08:07 +0100, Jan Beulich wrote:
>> >>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote:
>> &g
>>> On 10.10.11 at 18:49, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 08, 2011 at 10:13:14AM +0400, rush wrote:
>> OK, I tried it again, but Oops didn't gone.
> .. snip..
>> echo'Loading Xen 4.0-amd64 ...'
>> multiboot /boot/xen-4.0-amd64.gz placeholder xsave=0
> .. snip..
>>> Jeremy Fitzhardinge 25.11.09 22:24 >>>
>On 11/25/09 02:22, Jan Beulich wrote:
>> Okay, I think I spotted the relevant difference: 2.6.18 and forward ports
>> set VGCF_in_syscall only when returning from 64-bit system calls (through
>> ret_from_sys_cal
>>> Ian Campbell 23.11.09 17:44 >>>
>On Mon, 2009-11-23 at 16:31 +, Jan Beulich wrote:
>> >> It does not happen on XenSource 2.6.18 kernel
>> >
>> >I assume that this kernel (perhaps coincidentally) manages to use
>> >FLAT_USER_CS32
>>> Ian Campbell 23.11.09 16:25 >>>
>Perhaps simply not returning guest userspace with sysret (as above)
>makes most sense, a syscall already takes a trap through the hypervisor
>on both entry and exit so I'm not sure the difference between sysret and
>iret is going to be noticeable.
But this is
16 matches
Mail list logo
