On Tue, Aug 21, 2007 at 01:15:22PM -0700, Matthew Kent wrote:
On Tue, 2007-21-08 at 21:40 +0200, Luca wrote:
On 8/21/07, Matthew Kent [EMAIL PROTECTED] wrote:
On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote:
plain text document attachment (clock-hpet)
Linux operates the HPET
Dan Kenigsberg wrote:
On Tue, Aug 21, 2007 at 01:15:22PM -0700, Matthew Kent wrote:
On Tue, 2007-21-08 at 21:40 +0200, Luca wrote:
On 8/21/07, Matthew Kent [EMAIL PROTECTED] wrote:
On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote:
plain text document
Avi Kivity wrote:
Yang, Sheng wrote:
This patch enabled TPR shadow of VMX on CR8 access. 64bit Windows
using CR8
access TPR frequently. The TPR shadow can improve the performance of
access
TPR by not causing vmexit.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
Notice: This patch based on
The modified patch. Thanks.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
---
drivers/kvm/irq.h |2 +
drivers/kvm/lapic.c | 17 +
drivers/kvm/vmx.c | 63
++
drivers/kvm/vmx.h
Yang, Sheng wrote:
Wait, which lapic5 is broken and which is okay?!
Can you explain? maybe post sha1 hashes?
Sorry for not describe it clearly.
The ordinary lapic5 branch is broken now, we can make, but running it
would result in host crash(we mostly using module). Eddie found
Cam Macdonell wrote:
Avi Kivity wrote:
Weiyang Chen wrote:
A hardware task switch is sometimes used when a guest detects a
serious error and wants to switch to a known condition. Sometimes it
happens accidentally due to a previous error.
Was this image installed using kvm? What HAL
[Patch 2/3]
This introduces the Kconfig Makefile changes as well as creating the
still empty body of kvm_x86.*
Related part from the 0/3 mail:
- Since architecture will not change at runtime I do not use a arch_ops
structure
- Instead I used a hidden Kconfig value specifying the kvm
[Patch 1/3]
This is just a renaming patch converting _arch_ to _x86_ as I posted it
last week.
It ensures a better readability by preventing two _arch interfaces in
the code at the
same time.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
+49
Hello,
these three patches in v0 are be a base for discussion about an architecture
independence layer. It is part of an internal prototype we use to access
the code
of our port as we develop it currently.
I know that a lot of things in the patches are still needing refining and
polishing, but it
+struct desc_pages
+{
+/* Page of descriptors. */
+struct lguest_desc desc[NUM_DESCS];
+
+/* Next page: how we tell other side what buffers are available.
*/
+unsigned int avail_idx;
+unsigned int available[NUM_DESCS];
+char pad[PAGE_SIZE - (NUM_DESCS+1) *
1. Could not create kvm guest with memory =2040
https://sourceforge.net/tracker/index.php?func=detailaid=1736307group
_id=
180599atid=893831
https://sourceforge.net/tracker/index.php?func=detailaid=1736307grou
p_id
=180599atid=893831
This ought to be fixed for the next run (only on 64-bit
Am Mittwoch, 22. August 2007 schrieb Dor Laor:
Actually while playing with virtio for kvm Avi saw that and recommended
to do the following:
struct desc_pages
{
/* Page of descriptors. */
union {
struct virtio_desc desc[NUM_DESCS];
char
Christian Ehrhardt wrote:
Basics I used:
- Since architecture will not change at runtime I do not use a arch_ops
structure
- Instead I used a hidden Kconfig value specifying the kvm architecture
which then
influence the make file to link together the generic and the arch
specific part
Christian Ehrhardt wrote:
[Patch 2/3]
This introduces the Kconfig Makefile changes as well as creating the
still empty body of kvm_x86.*
Related part from the 0/3 mail:
- Since architecture will not change at runtime I do not use a
arch_ops structure
- Instead I used a hidden Kconfig
Christian Ehrhardt wrote:
[Patch 3/3]
This patch moves the arch specific x86 code from kvm_main.c to
kvm_x86.c and fills the kvm_arch.h
header defining the current interface.
Related part from the 0/3 mail:
- A new header kvm_arch.h specifies the interface the architecture has
to
Actually while playing with virtio for kvm Avi saw that and
recommended
to do the following:
struct desc_pages
{
/* Page of descriptors. */
union {
struct virtio_desc desc[NUM_DESCS];
char pad1[PAGE_SIZE];
};
[...]
Fine with me. Is anybody
Rusty Russell wrote:
On Wed, 2007-08-22 at 02:26 -0700, Dor Laor wrote:
Actually while playing with virtio for kvm Avi saw that and recommended
to do the following:
struct desc_pages
{
/* Page of descriptors. */
union {
struct virtio_desc desc[NUM_DESCS];
i have wrote a patch that let kvm share the ( for now 1024 ) mmu pages
of all the guests.
the patch is wrote in a way that it take mmu pages from idle guest and
move them to intensive working guest.
i have design the patch from the beginning to not use locking at all.
therefore when the
Yang, Sheng wrote:
The modified patch. Thanks.
Applied to rebased branch; thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping
KVM BIOS uses the following code to delay an expected milliseconds
void delay_ms(int n)
{
int i, j;
for(i = 0; i n; i++) {
/* approximative ! */
for(j = 0; j 100; j++);
}
}
It's OK when we run APIC in user level, but when APIC is in kernel, the
delayed time is
Now on lapic5 branch, we can run Windows guests, both 32bit and 64bit
are OK, but Linux still has problems.
And we will send out the SMP patches for review soon.
-Xin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Li, Xin B
Sent: Wednesday, August 22,
Just rebased to the latest lapic5 branch, found SMP patch is there, so
kernel APIC SMP is working on your side?
But I don't think you can even pass BIOS CPU enumeration.
-Xin
-Original Message-
From: Li, Xin B
Sent: Wednesday, August 22, 2007 10:17 PM
To: Li, Xin B;
Li, Xin B wrote:
Just rebased to the latest lapic5 branch, found SMP patch is there, so
kernel APIC SMP is working on your side?
But I don't think you can even pass BIOS CPU enumeration.
If it got there, it's something in progress that wasn't meant to be pushed.
Do a 'git reset --hard
The lapic branch is still stalled on smp, but Windows x64 and large
memory support are each a good reason for a release, so here's kvm-36.
Changes from kvm-35:
- support guests with more than 2GB of RAM on 64-bit hosts (Izik Eidus)
- fix rare host oops on guest context switch
- avoid
Luca Tettamanti wrote:
Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto:
Luca Tettamanti wrote:
Actually I'm having troubles with cyclesoak (probably it's calibration),
numbers are not very stable across multiple runs...
I've had good results with
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.100.002966 0 96840 clock_gettime
19.500.001110 0 37050
I've installed vista premium home 32 bit on previous versions of kvm,
namely 24-1 which is packaged with fedora 7. Since then I've removed these
packages and building kvm from releases from sourceforge provided qumranet
website. When I try to install vista premium home 32 bit using kvm release
36
On 8/22/07, Avi Kivity [EMAIL PROTECTED] wrote:
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.100.002966 0 96840
I saw the same issue on my AMD Turion notebook.
-Wei
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Haydn
Solomon
Sent: Wednesday, August 22, 2007 11:53 AM
To: kvm-devel@lists.sourceforge.net
Subject: [kvm-devel] Vista 32 Premium 32 bit gets
On 8/22/07, Luca [EMAIL PROTECTED] wrote:
I see a lot of sub ms timer_settime(). Many of them are the result of
-expire_time being less than the current qemu_get_clock().
False alarm, this was a bug in the debug code :D
Luca
I noticed the idle cpu usage for kvm-36 running windows xp 32 bit as
guest is much higher.
For kvm-35 this was around 2-4%, running kvm-36 it's 22% - 26%.
2007/8/22, Avi Kivity [EMAIL PROTECTED]:
The lapic branch is still stalled on smp, but Windows x64 and large
memory support are each a good
I didn't notice this till you mentioned it. I'm also running windows xp 32
bit and seeing much higher cpu usage on kvm-36 as opposed to very low on
kvm-35.
On 8/22/07, Gunther Persoons [EMAIL PROTECTED] wrote:
I noticed the idle cpu usage for kvm-36 running windows xp 32 bit as
guest is much
On 8/22/07, Luca [EMAIL PROTECTED] wrote:
On 8/22/07, Avi Kivity [EMAIL PROTECTED] wrote:
Luca wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
52.10
Hey,
I justw anted to note, that I can't confirm this behavior fpr Windows
2003 Server guests. Usage is about 4-6%.
- fabiand
Am Mittwoch, den 22.08.2007, 15:12 -0400 schrieb Haydn Solomon:
I didn't notice this till you mentioned it. I'm also running windows
xp 32 bit and seeing much higher
AMD or Intel processors?
On 8/22/07, Gunther Persoons [EMAIL PROTECTED] wrote:
I noticed the idle cpu usage for kvm-36 running windows xp 32 bit as
guest is much higher.
For kvm-35 this was around 2-4%, running kvm-36 it's 22% - 26%.
2007/8/22, Avi Kivity [EMAIL PROTECTED]:
The lapic
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
On 8/22/07, Gunther Persoons [EMAIL PROTECTED] wrote:
Intel T2400
2007/8/22, Duncan McQueen [EMAIL PROTECTED]:
AMD or Intel processors?
On 8/22/07, Gunther Persoons [EMAIL PROTECTED] wrote:
I noticed the idle cpu usage
On Wed, Aug 22, 2007 at 06:38:18PM +0200, Luca wrote:
and I'm reading it from /proc/config.gz on the guest.
And a huge number of settime calls?
Yes, maybe some QEMU timer is using an interval 1ms?
Dan do you any any idea of what's going on?
Not really...
On Wed, Aug 22, 2007 at 02:34:24PM +0200, Andi Kleen wrote:
On Wed, Aug 22, 2007 at 10:03:32AM +0300, Avi Kivity wrote:
Maybe the kernel is using the timer, so userspace can't. Just a guess.
HPET has multiple timers (variable, but typically 2 or 4). The kernel
only uses timer 0. It's
$ dmesg |grep -i hpet
ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97)
ACPI: HPET id: 0x8086a301 base: 0xfed0
hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
hpet0: 4 64-bit timers, 14318180 Hz
hpet_resources: 0xfed0 is busy
What kernel version was that? There was a
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
-
---
52.100.002966 0 96840
clock_gettime
19.500.001110 0 37050
timer_gettime
On 8/22/07, Dor Laor [EMAIL PROTECTED] wrote:
This is QEMU, with dynticks and HPET:
% time seconds usecs/call callserrors syscall
-- --- --- - -
-
---
52.100.002966 0 96840
clock_gettime
How did you test your patch? PXE boot hasn't ever worked with
qemu-system-x86_64. I never dug into it because I didn't use it
(although now I do since KVM uses it by default). I don't know that
it's worth pulling in the PXE boot fix until we figure out why it
doesn't work on qemu-system-x86_64
Sorry for forgot to mention that this patch is for lapic5 tree. And it
replaced the Reading PPR directly from function rather than apic page
thanks.
Yang, Sheng wrote:
After TPR Shadow feature introduced, many TPR access won't cause
vmexit, so
the ordinary point of catching TPR and updating
On 8/22/07, Anthony Liguori [EMAIL PROTECTED] wrote:
How did you test your patch? PXE boot hasn't ever worked with
qemu-system-x86_64.
Really? It worked for me (qemu-system-x86_64 from kvm28, atftpd
serving i386 dapper ubuntu-installer image over tap networking
device). Could you clarify
44 matches
Mail list logo
