Matthew Kent wrote:
> ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
>
>
Well, we now have the bios in kvm-userspace.git (under bios/). If
someone wants a go at adding DMI to the bios, it's waiting for you.
--
Do not meddle in the internals of kernels, for they are subtle and
the system is now MUCH faster! it boots really fast, i think, in the
init-scripts there are much "sleep x", and every "x" were "2*x" in
reality.
other tasks are also much faster
i'm happy now :-)
although i cannot reboot ... (it hangs after halted), but that is
another thread.
Am Donnerstag, d
Matthew, your the hero of the day!
with "acpi=force" in the guest the clock ticks correct.
> ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
is it possible to use another bios where the acpi=force switch is not
needed? or to fix the bios (i think kvm uses it's own bios, not the
ori
[oops sorry. should have included the full dmesg from the bad boot and
cc'd the original poster]
On Thu, 2007-09-08 at 16:23 -0700, Matthew Kent wrote:
> On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote:
> > hi,
> >
> > im using a 64 bit fedora7 system with a quad-core processor to host
On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote:
> hi,
>
> im using a 64 bit fedora7 system with a quad-core processor to host
> multiple virtual machines.
>
literally the exact same setup here
> my current kernel is:
>
> Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 ED
ok,
patched kvm-33, compile, install
i started qemu-system-x86_64 with "-no-rtc -use-hpet" and ... well the
time drift is unchanged. ok, the warning for "dev.rtc..." has gone.
doing a date (guest) gives me (for example):
8:08:59
after 10 (real!) seconds, date (guest) gives me
8:09:04
--> 10
Il Tue, Aug 07, 2007 at 02:08:08PM +0200, Luca ha scritto:
> On 8/7/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> > Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some
> > new chipsets implement rtc using HPET).
>
> Basically HPET can operate in legacy mode - where it uses the sam
>>> Basically HPET can operate in legacy mode - where it uses the same
>>> IRQ as the RTC (and RTC won't deliver any interrupt) - or in
>>> "standard" mode where the IO-APIC can be configured to deliver the
>>> interrupt on any line. ATM Linux can only use the legacy mode.
>>> You can of course dis
[EMAIL PROTECTED] wrote:
>>> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know
>>> some new chipsets implement rtc using HPET).
>>
>> Basically HPET can operate in legacy mode - where it uses the same
>> IRQ as the RTC (and RTC won't deliver any interrupt) - or in
>> "standard" mo
> We're experiencing guest clock drifts even when the host is running with
> HZ=1000.
> But so far there were no performance problmes around it.
> It's worth a shot anyway.
>
are there any benchmarkings (and tools) which i can run inside the
guest? are there any official results with which i ca
>> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know
>some
>> new chipsets implement rtc using HPET).
>
>Basically HPET can operate in legacy mode - where it uses the same IRQ
>as the RTC (and RTC won't deliver any interrupt) - or in "standard"
>mode where the IO-APIC can be config
well there are running some "default F7 daemons".
yum-updatesd (python)
setroubleshootd (python)
hald
...
but no process is really running, when doing a "htop" i the processor
has a load of 0.7%
what is the "efer_reload"?
while i'm writing this email i have kvm_stat in another shell in the
back
On 8/7/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some
> new chipsets implement rtc using HPET).
Basically HPET can operate in legacy mode - where it uses the same IRQ
as the RTC (and RTC won't deliver any interrupt) - or in "standa
>today morning i compiled kvm-33 and the output of kvm-stat is much
>better now (guest in idle):
>
>kvm statistics
>
> efer_reload 109442736504
> exits137226886967
> halt_exits1084344 935
> invlpg 0 0
> io_exits 76689145070
> irq_exits 2788
On 8/7/07, Ulrich Schreiner <[EMAIL PROTECTED]> wrote:
> Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a
> fatal
> error, but for better emulation accuracy either use a 2.6 host Linux
> kernel or
> type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
>
> well i HAVE a 2
today morning i compiled kvm-33 and the output of kvm-stat is much
better now (guest in idle):
kvm statistics
efer_reload 109442736504
exits137226886967
halt_exits1084344 935
invlpg 0 0
io_exits 76689145070
irq_exits 27886 2
>no ideas what can be done? why it is so slow?
Let's try to catch the cause for the 74k ioexits per second.
Please add #define DEBUG_IOPORT in qemu/vl.c and qemu/exec.c and
recompile.
After that when the guest runs and does 74k ioexits on idle, enter the
qemu's monitor (ctrl-alt-1)
enter 'log iopo
no ideas what can be done? why it is so slow?
i've tried the "-L /usr/shar/kvm" to use the kvm-bios but no better
performance ...
Am Donnerstag, den 02.08.2007, 11:24 +0300 schrieb Avi Kivity:
> Ulrich Schreiner wrote:
> > dmesg|grep kvm
> >
> > SELinux: initialized (dev kvmfs, type kvmfs), uses
/sbin/hdparm /dev/sda
/dev/sda:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead= 256 (on)
geometry = 3263/255/63, sectors = 52428800, start = 0
top in the guest-vm shows nothing special
top - 10:27:37 up 13:09, 2 users, load average: 0.05, 0.07, 0.02
Tasks:
Ulrich Schreiner wrote:
> dmesg|grep kvm
>
> SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts
> kvm: emulating exchange as write
>
>
There may be messages that aren't prefixed with 'kvm:' (that's a bug
btw). Please check.
> now booting into a F7 image, after the system is re
dmesg|grep kvm
SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts
kvm: emulating exchange as write
now booting into a F7 image, after the system is ready (and in idle):
top
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
14917 root 20 0 332m 71m 66m
Ulrich Schreiner wrote:
> hi,
>
> im using a 64 bit fedora7 system with a quad-core processor to host
> multiple virtual machines.
>
> my current kernel is:
>
> Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
> (now there is a 2.6.22.1-33.fc7
hi,
im using a 64 bit fedora7 system with a quad-core processor to host
multiple virtual machines.
my current kernel is:
Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux
(now there is a 2.6.22.1-33.fc7 to download, but i think it is not the
poi
23 matches
Mail list logo