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=detail&atid=893831&aid=1877875&group_id=180599
Please note that this message will contain a full copy
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 co
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=detail&atid=893831&aid=1872539&gro
up_id
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=detail&atid=893831&aid=1872539&gro
up
Get the best girls arounf! http://ou.
The system is temporary busy, try to access it later. No data
can be lost.
Copyright © SpamIt.com 2007, All rights
reserved.
-
This SF.net email is spons
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 #
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/
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
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, 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 Tue, 22 Jan 2008, Andrea Arcangeli wrote:
> First it makes me optimistic this can be merged sooner than later to
> see a second brand new implementation of this ;).
Brand new? Well this is borrowing as much as possible from you
> > The problem that I have with this is still that there is
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 updat
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
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 ha
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
n
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. Microsof
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-devel&m=120103225508669&w=2
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 b/arch/x8
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,
While starting a kernel
Unable to handle kernel NULL pointer dereference at 0008 RIP:
[] :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
rge_full_design
CPU 0
Mo
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 --gi
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
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
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
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 se
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).
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
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
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
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 th
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.
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 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 o
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
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 refer
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 mo
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
>>
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;
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-m
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 =
> + &kv
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_se
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:
> 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:
> 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.
>
>
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=detail&atid=893831&aid=1877273&group_id=180599
Please note that this message will contain a full copy
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
--
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_updat
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 d
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
-
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
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+
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,
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
> 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,
>
54 matches
Mail list logo
