Avi Kivity wrote:
> [Resurrecting post from the dead]
>
>
> Marcelo Tosatti wrote:
>> Forcing clustered APIC mode works only on SMP, and there were high CPU
>> consumption on Windows SMP guests due to C3 state being reported (fixed
>> in kvm-30 something).
>>
>> So perhaps:
>> - Faking clustered AP
[Resurrecting post from the dead]
Marcelo Tosatti wrote:
> Forcing clustered APIC mode works only on SMP, and there were high CPU
> consumption on Windows SMP guests due to C3 state being reported (fixed
> in kvm-30 something).
>
> So perhaps:
> - Faking clustered APIC on SMP
> - Faking C3 on UP
Marcelo Tosatti wrote:
> Avi, do you understand why C3 was causing the Windows SMP problems ?
>
>
It may be that the latency was advertised as so low that Windows
switched into C3 and back too often.
Also, the problem possibly wasn't SMP related but rather TPR related --
when the idle loop c
Avi Kivity writes:
> Thanks; that's reassuring to know that it will work (at least on Intel).
Actually there are modern Intel systems which still have instable TSCs;
e.g. IBM Summit multi node systems and some others. So you should
still handle that case.
-Andi
-
> And turning of the TSC bit (for 32-bit guests).
Turning off the TSC bit will break 64bit Linux (it checks
if the cpuid bits have minimum supported features) and you don't know
in advantage if a guest is 32bit or not.
Ok there is a special BIOS call that the kernel issues to tell
the BIOS that
On Wed, Jan 16, 2008 at 02:54:15PM +0100, Andi Kleen wrote:
> On Wed, Jan 16, 2008 at 03:38:45PM +0200, Avi Kivity wrote:
> > Andi Kleen wrote:
> > >Linux checks a couple of things: e.g. if there are no deep C states
> > >and if there are no clustered nodes in the APIC etc.
> > >
> > >It might be r
Andi Kleen wrote:
> Check if host is using TSC source and if not force a clustered
> APIC mode (only works for 64bit unfortunately) or fake a C3 state
> in ACPI and on AMD clear the synchronous TSC bit.
>
Yes, I got similar suggestions from Thomas. But it looks like older
guests will need a b
On Wed, Jan 16, 2008 at 03:38:45PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> >Linux checks a couple of things: e.g. if there are no deep C states
> >and if there are no clustered nodes in the APIC etc.
> >
> >It might be reasonable to check the clock source of the kernel
> >and if it's not TSC
On Wed, Jan 16, 2008 at 10:46:11AM +0200, Avi Kivity wrote:
> [fixing gmane emails, urgfhsz]
>
> Andi Kleen wrote:
> >Avi Kivity writes:
> >
> >
> >>Thanks; that's reassuring to know that it will work (at least on Intel).
> >>
> >
> >Actually there are modern Intel systems which still have
[fixing gmane emails, urgfhsz]
Andi Kleen wrote:
> Avi Kivity writes:
>
>
>> Thanks; that's reassuring to know that it will work (at least on Intel).
>>
>
> Actually there are modern Intel systems which still have instable TSCs;
> e.g. IBM Summit multi node systems and some others. So you
On Tuesday 15 January 2008 23:16:46 Avi Kivity wrote:
> Alexander Graf wrote:
> > If I remember correctly, there was a statement on LKML by AMD which said
> > that the TSC is completely broken on AMD systems, so you should not use
> > it there anyway.
>
> Well, that's up to the guest to decide. Lo
Alexander Graf wrote:
> If I remember correctly, there was a statement on LKML by AMD which said
> that the TSC is completely broken on AMD systems, so you should not use
> it there anyway.
>
Well, that's up to the guest to decide. Looks like older Linux guests
make the wrong decision.
Avi Kivity wrote:
> Alexander Graf wrote:
>
>>> What I mean is, right now we present really broken tscs to the guest.
>>> After your patch, we present less-broken tscs (at boot, they will
>>> closely resemble stable tscs). But after the machine idl
Alexander Graf wrote:
>>>
>>>
>>>
>> What I mean is, right now we present really broken tscs to the guest.
>> After your patch, we present less-broken tscs (at boot, they will
>> closely resemble stable tscs). But after the machine idles a bit and
>> cpufreq takes over, the tscs
Marcelo Tosatti wrote:
> So the first patch seemed alright (taking into account the comments from
> my previous email, that migration should probably be fixed in a separate
> patch since its broken already and that its guaranteed that vcpu0 is the
> first to hit vcpu_load).
>
I really would lik
Avi Kivity wrote:
> Marcelo Tosatti wrote:
>
>> Hi Avi,
>>
>> On Sun, Jan 13, 2008 at 02:19:29PM +0200, Avi Kivity wrote:
>>
>>
>>> Marcelo Tosatti wrote:
>>>
>>>
The boot TSC sync check is failing on recent Linux SMP guests on TSC
stable hosts.
Marcelo Tosatti wrote:
> Hi Avi,
>
> On Sun, Jan 13, 2008 at 02:19:29PM +0200, Avi Kivity wrote:
>
>> Marcelo Tosatti wrote:
>>
>>> The boot TSC sync check is failing on recent Linux SMP guests on TSC
>>> stable hosts.
>>>
>>>
>>>
>> What about tsc unstable hosts? If your patch co
On Mon, Jan 14, 2008 at 02:06:47PM -0200, Marcelo Tosatti wrote:
> Hi Avi,
>
> On Sun, Jan 13, 2008 at 02:19:29PM +0200, Avi Kivity wrote:
> > Marcelo Tosatti wrote:
> > >The boot TSC sync check is failing on recent Linux SMP guests on TSC
> > >stable hosts.
> > >
> > >
> >
> > What about tsc u
Hi Avi,
On Sun, Jan 13, 2008 at 02:19:29PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> >The boot TSC sync check is failing on recent Linux SMP guests on TSC
> >stable hosts.
> >
> >
>
> What about tsc unstable hosts? If your patch convinces the guest its
> tsc is table, while the host
Marcelo Tosatti wrote:
> The boot TSC sync check is failing on recent Linux SMP guests on TSC
> stable hosts.
>
>
What about tsc unstable hosts? If your patch convinces the guest its
tsc is table, while the host tsc is not, then it may cause confusion
later on.
> Following patch attempts to
Will Trives wrote:
> Hello,
>
> 64 bit environment Intel Q6600 processor.
>
> I did hand apply the patch so I might have got something wrong.
>
> Guest was a 32 bit kubuntu 7.10.
>
> Basically I just mounted a few disk images with " -drive
> file=/whatever,if=scsi " and used gparted to copy a parti
Hello,
64 bit environment Intel Q6600 processor.
I did hand apply the patch so I might have got something wrong.
Guest was a 32 bit kubuntu 7.10.
Basically I just mounted a few disk images with " -drive
file=/whatever,if=scsi " and used gparted to copy a partition from one
to the other.
It's p
On Sat, Jan 12, 2008 at 02:11:30PM +1100, Will Trives wrote:
> Hello,
>
> Just thought i'd mention that this patch caused disk corruption in my
> virtual machines, particularly when using scsi emulation.
>
> I got few errors like this as well:
>
> lsi_scsi: error: ORDERED queue not implemented
>
Hello,
Just thought i'd mention that this patch caused disk corruption in my
virtual machines, particularly when using scsi emulation.
I got few errors like this as well:
lsi_scsi: error: ORDERED queue not implemented
lsi_scsi: error: IO with unknown tag 65577
Regards,
Will
-
The boot TSC sync check is failing on recent Linux SMP guests on TSC
stable hosts.
Following patch attempts to address the problems, which are:
1) APIC_DM_STARTUP, which is only called for vcpu's other than vcpu0,
will trigger ->vcpu_reset(), setting the TSC to 0. Fix that by moving
the guest_wr
25 matches
Mail list logo
