On Fri, 18 Jan 2008 22:56:32 +0530 Balbir Singh [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] [2008-01-17 02:35:14]:
- kvm probably doesn't work properly because I couldn't be bothered fixing
the conflicts between git-kvm and the driver tree
Hi, Andrew,
The
Hi,
Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should
probably kill qemu then, since the machine might have no acpid running -
in that case hitting ctrl-c would have no effect.
Good idea.
I'm worried about the 30+ second shutdown latency. Is there precedent
Carlo Marcelo Arenas Belon wrote:
On Mon, Jan 21, 2008 at 01:46:11PM +0100, Jan Kiszka wrote:
Here are 4 more warnings fixes (actually, I should sent 2 of them to
qemu...). Nothing critical, just less noise during compilation.
probably a good idea having them in independent patches as they
Gerd Hoffmann wrote:
Hi,
Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should
probably kill qemu then, since the machine might have no acpid running -
in that case hitting ctrl-c would have no effect.
Good idea.
I'm worried about the 30+ second shutdown latency.
Liu, Eric E wrote:
From ab229d437b59317a322ca0efd2b0d239b74e Mon Sep 17 00:00:00 2001
From: Feng(Eric) Liu [EMAIL PROTECTED]
Date: Tue, 22 Jan 2008 17:01:29 -0500
Subject: [PATCH] kvm: mmu: fix a potential issue
Since the type of gpa is u64, so extend pte_size to u64. Otherwise, a
Guido Guenther wrote:
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state-pmen PWRBTN_EN) {
+ pm_state-pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
This code should also care about !pm_state, ie. non-PCI systems.
Jan
---
On Tue, Jan 22, 2008 at 11:11:00AM +0100, Jan Kiszka wrote:
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
+if (!pm_state)
+exit(0);
if(pm_state-pmen PWRBTN_EN) {
pm_state-pmsts |= PWRBTN_EN;
pm_update_sci(pm_state);
This totally defeats the
Guido Guenther wrote:
On Tue, Jan 22, 2008 at 11:11:00AM +0100, Jan Kiszka wrote:
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
+if (!pm_state)
+exit(0);
if(pm_state-pmen PWRBTN_EN) {
pm_state-pmsts |= PWRBTN_EN;
pm_update_sci(pm_state);
Andrea Arcangeli wrote:
On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
Yes, it's supposed to work (we can't prevent userspace from doing it).
Hmm, I think we already prevent it, so I don't think I need to update
my swap code until the below is removed.
/* Check
Andrea Arcangeli wrote:
I still can't see how it could be possibly make a difference for the
mm_count if the kvm module is compiled inside the kernel or as an
external module, the reference counting there hasn't changed since
ages. The mmdrop fires only in the first overflow so even if I'm
Andrea Arcangeli wrote:
This is the kvm-userland patch needed to compile kvm.git as an
external module on a kernel w/ MMU_NOTIFIER=n with the kvm swapping
patch applied to kvm.git.
Will apply once mmu notifiers are merged into mainline, to prevent
needless churn.
--
error compiling
Andrea Arcangeli wrote:
This adds locking to the memslots so they can be looked up with only
the mmu_lock. Entries with memslot-userspace_addr have to be ignored
because they're not fully inserted yet.
What is the motivation for this? Calls from mmu notifiers that don't
have mmap_sem
Yang, Sheng wrote:
+
+/* Compute with 96 bit intermediate result: (a*b)/c */
+static u64 muldiv64(u64 a, u32 b, u32 c)
Why do we need such high accuracy for the pit?
+
+static int pit_get_out(struct kvm *kvm, int channel)
+{
+ struct PITChannelState *c =
+
Bugs item #1877273, was opened at 2008-01-22 13:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1877273group_id=180599
Please note that this message will contain a full copy of
Jan Kiszka wrote:
While trying to reduce the warning noise (to identify warnings of
homebrewed patches), I also came across this bogus but fortunately
harmless type change in bdrv_commit. Fix below.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
Andrea Arcangeli wrote:
This is the same as before but it uses the age_page callback to
prevent the guest OS working set to be swapped out. It works well here
so far. This depends on the memslot locking with mmu lock patch and on
the mmu notifiers #v3 patch that I'll post in CC with linux-mm
Andrea Arcangeli wrote:
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -44,8 +44,10 @@
({ \
int __young;
On Tue, Jan 22, 2008 at 03:41:02PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
I still can't see how it could be possibly make a difference for the
mm_count if the kvm module is compiled inside the kernel or as an
external module, the reference counting there hasn't changed since
ages.
Andrea Arcangeli wrote:
This is arch independent code, I'm surprised mmu_lock is visible here?
The mmu_lock is arch independent as far as I can tell. Pretty much
like the mm-page_table_lock is also independent. All archs will have
some form of shadow pagetables in software or hardware,
On Tue, Jan 22, 2008 at 04:08:16PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
This is the same as before but it uses the age_page callback to
prevent the guest OS working set to be swapped out. It works well here
so far. This depends on the memslot locking with mmu lock patch and on
the
On Tue, Jan 22, 2008 at 04:12:34PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -44,8 +44,10 @@
({
On Tue, Jan 22, 2008 at 03:37:59PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
Yes, it's supposed to work (we can't prevent userspace from doing it).
Hmm, I think we already prevent it, so I don't think I need to
Andrea Arcangeli wrote:
On Tue, Jan 22, 2008 at 04:08:16PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
This is the same as before but it uses the age_page callback to
prevent the guest OS working set to be swapped out. It works well here
so far. This depends on the memslot
Andrea Arcangeli wrote:
On Tue, Jan 22, 2008 at 03:41:02PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
I still can't see how it could be possibly make a difference for the
mm_count if the kvm module is compiled inside the kernel or as an
external module, the reference counting
On Tue, Jan 22, 2008 at 04:38:49PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
This is arch independent code, I'm surprised mmu_lock is visible here?
The mmu_lock is arch independent as far as I can tell. Pretty much
like the mm-page_table_lock is also independent. All archs will
On Tue, Jan 22, 2008 at 03:47:28PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
This adds locking to the memslots so they can be looked up with only
the mmu_lock. Entries with memslot-userspace_addr have to be ignored
because they're not fully inserted yet.
What is the motivation for
Hi all,
I've got a Vaio VGN-SZ1VP_C. As you can read here¹, Sony disabled
VT (and AHCI) by BIOS. So, when I try to load KVM module I've got:
kvm: disabled by bios
Is it possible to ignore BIOS settings (without hacking with hardware)?
Thanks a lot for your time and work,
Andrea
Andrea Gelmini wrote:
Hi all,
I've got a Vaio VGN-SZ1VP_C. As you can read here¹, Sony disabled
VT (and AHCI) by BIOS. So, when I try to load KVM module I've got:
kvm: disabled by bios
Is it possible to ignore BIOS settings (without hacking with hardware)?
no,
but you can try looks
Andrea Arcangeli wrote:
On Tue, Jan 22, 2008 at 03:37:59PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
Yes, it's supposed to work (we can't prevent userspace from doing it).
Hmm, I think we
On Tue, 2008-01-22 at 17:59 +0200, Izik Eidus wrote:
Andrea Gelmini wrote:
Hi all,
I've got a Vaio VGN-SZ1VP_C. As you can read here¹, Sony disabled
VT (and AHCI) by BIOS. So, when I try to load KVM module I've got:
kvm: disabled by bios
Is it possible to ignore BIOS settings
On Tue, Jan 22, 2008 at 06:17:38PM +0200, Avi Kivity wrote:
There can be more than one rmapp per hva. Real world example:
memslot 1: gfn range 0xe00 - 0xe080 @ hva 0x1000 (8MB
framebuffer)
memslot 2: gfn range 0xa - 0xa8000 @ hva 0x1000 (32KB VGA window)
If the guest
On Tue, Jan 22, 2008 at 06:18:08PM +0200, Dor Laor wrote:
On Tue, 2008-01-22 at 17:59 +0200, Izik Eidus wrote:
Andrea Gelmini wrote:
Hi all,
I've got a Vaio VGN-SZ1VP_C. As you can read here¹, Sony disabled
VT (and AHCI) by BIOS. So, when I try to load KVM module I've got:
kvm:
On Tue, Jan 22, 2008 at 04:53:37PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
On Tue, Jan 22, 2008 at 04:08:16PM +0200, Avi Kivity wrote:
Andrea Arcangeli wrote:
This is the same as before but it uses the age_page callback to
prevent the guest OS working set to be swapped out.
Change the Makefile in kernel/ to explicitly call GNU awk if its not the
default awk installed (like in Ubuntu). This fixes a build error seen on Ubuntu
7.10.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
---
kernel/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
While starting a kernel
Unable to handle kernel NULL pointer dereference at 0008 RIP:
[885698fd] :kvm_amd:svm_vcpu_run+0x35/0x30d
PGD 471e1067 PUD 54ca9067 PMD 0
Oops: [1] SMP
last sysfs
file: /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/cha
This last update will work against mmu-notifiers #v4, this will make
the accessed bitflag in the spte visible to the linux VM so it will
provide an accurate working set detection w/o requiring vmexits.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/Kconfig
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 47c10b8..7b931a8 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2573,7
This last update avoids the need to refresh the young bit in the linux
pte through follow_page and it allows tracking the accessed bits set
by the hardware in the sptes without requiring vmexits in certain
implementations.
KVM side is here:
http://marc.info/?l=kvm-develm=120103225508669w=2
On Tue, 22 Jan 2008, Peter Zijlstra wrote:
I think we can get rid of this rwlock as I think this will seriously
hurt larger machines.
Correct.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges.
On Tue, Jan 22, 2008 at 08:28:47PM +0100, Peter Zijlstra wrote:
I think we can get rid of this rwlock as I think this will seriously
hurt larger machines.
Yep, I initially considered it, nevertheless given you solved part of
the complication I can add it now ;). The only technical reason for
On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
This last update avoids the need to refresh the young bit in the linux
pte through follow_page and it allows tracking the accessed bits set
by the hardware in the sptes without requiring vmexits in certain
implementations.
The problem that I have
On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
Then I will have to update KVM so that it will free the kvm structure
after waiting a quiescent point to avoid kernel crashing memory
corruption after applying your changes to the mmu notifier.
It may not be suitable (I've not looked into your
Hi Christoph,
Just a few early comments.
First it makes me optimistic this can be merged sooner than later to
see a second brand new implementation of this ;).
On Tue, Jan 22, 2008 at 12:34:46PM -0800, Christoph Lameter wrote:
On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
This last update
On Tue, 2008-01-22 at 12:34 -0800, Christoph Lameter wrote:
- Notifiers are called *after* we tore down ptes. At that point pages
may already have been freed and reused. This means that there can
still be uses of the page by the user of mmu_ops after the OS has
dropped its mapping.
On Wed, 23 Jan 2008, Benjamin Herrenschmidt wrote:
- anon_vma/inode and pte locks are held during callbacks.
So how does that fix the problem of sleeping then ?
The locks are taken in the mmu_ops patch. This patch does not hold them
while performing the callbacks.
On Tue, Jan 22, 2008 at 04:40:50PM -0800, Christoph Lameter wrote:
On Wed, 23 Jan 2008, Benjamin Herrenschmidt wrote:
- anon_vma/inode and pte locks are held during callbacks.
So how does that fix the problem of sleeping then ?
The locks are taken in the mmu_ops patch. This patch
A Token of My Love http://81.190.4.250/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the
latest git kernel from Linus as of yesterday, slightly post 2.6.24-rc8.)
I found that it crashes very early, apparently because KVM doesn't
handle an #UD received in user mode. It appears that OS/2 actually
provokes an
Get the best girls arounf! http://ou.
!-- /top --
!-- content
--
table cellpadding=0 cellspacing=0
id=content_members_table
tr
td style=padding-left:162px;
div
style=padding-bottom:3px;padding-top:26px; font-size: 14px;br
/strongThe system is temporary busy, try to access it later. No
Hi, all,
This is today's KVM test result against kvm.git
3d12af8d03b98644df72c9ac59416d37ea000303 and kvm-userspace.git
37fc8ac95c8b9ae864ce732276c3936ef4a341bb.
One issue fixed:
1. Fails to boot 64bit guest with 4BG mem
https://sourceforge.net/tracker/?func=detailatid=893831aid=1872539gro
Hi, all,
We did a test on KVM60RC1, and 7 issues have been found in the test.
One issue fixed:
1. Fails to boot 64bit guest with 4BG mem --- Has already been fixed
by 29ae41a859a12aa71baacd35a9648511f335848e.
https://sourceforge.net/tracker/?func=detailatid=893831aid=1872539gro
On Tuesday 22 January 2008 21:54:10 Avi Kivity wrote:
Yang, Sheng wrote:
+
+/* Compute with 96 bit intermediate result: (a*b)/c */
+static u64 muldiv64(u64 a, u32 b, u32 c)
Why do we need such high accuracy for the pit?
The direct reason is we using TSC as the reference of pit
Bugs item #1877875, was opened at 2008-01-23 13:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1877875group_id=180599
Please note that this message will contain a full copy of
53 matches
Mail list logo
