Glauber de Oliveira Costa wrote:
> On 10/15/07, Izik Eidus <[EMAIL PROTECTED]> wrote:
>
> I just took a quick overview on it, but to start with, why does it use
> a vmx specific naming ?
>
>
beacuse the problem is in the emulator function that the vmx have to run
inside unsleepable mode for rea
This new patch removes gcc 3.x checks, as well as adds environment
variables $CFLAGS & $LDFLAGS to include libs to qemu for cross compile.
I was going to add this in another patch. But they should probably go in
now. So an example for power is to include zlib so before running
configure you do:
So it appears that trying to remove --cpu option will not work. Qemu
still wants to compile to the arch of the machine you are compiling on
without it. Even with cross compiler specified. So qemu still thinks the
host CPU is going to be i386, even though I specified an x86-64 cross
compilers. So Qe
On 10/15/07, Izik Eidus <[EMAIL PROTECTED]> wrote:
I just took a quick overview on it, but to start with, why does it use
a vmx specific naming ?
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
--
On 10/15/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> (This mail was sent off-list, so I'll do the same.)
Oh, I'm sorry Hollis, after so many mails, I've hit the reply key
instead of the reply to all one ;-)
I'm moving it to the list again, where it belongs.
> On Mon, 2007-10-15 at 14:29 -
> The basic issue is that on many architectures, the hardware MMU does
> *not* hold all mappings, and even if it does, performing MMU translation
> in software can be prohibitively complicated and slow. As a worst-case
> scenario, consider a software-controlled TLB which can hold a small
> finite n
On Mon, 2007-10-15 at 18:47 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> >>
> >> I'd think there is no reason for virtual timer to be PIT like, which
> >> is mostly due to historic reason.
> >>
> >> If we need to make it close to native timer device, HPET is much
> >> better than PIT for vi
On Mon, 2007-10-15 at 14:48 -0300, Glauber de Oliveira Costa wrote:
> On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > > + if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
> > > + return;
> >
> > Here you're passing a virtual address across the guest/host
Very nice!
This series seems to have solved the problem for me.
Izik Eidus wrote:
> this patch remove all the ugly messages from the dmesg,
> now i think my patch together with Anthony changes can be merged to kvm.
Perhaps you can send out all of the patches together in a single patch
bomb for
>From c5761ef6c1333062a7cd9d5b0003955bc7b7a93e Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 23:16:42 +0200
Subject: [PATCH] this patch make the injection of interrupts run at sleepable mode.
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
drivers/kvm/kv
>From d11f64d00e5fd5fdcd6c82bf819653f392e5ad2b Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 19:24:52 +0200
Subject: [PATCH] making update_dirty_bit get called without disabling preempt
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
drivers/kvm/paging_t
this patch remove all the ugly messages from the dmesg,
now i think my patch together with Anthony changes can be merged to kvm.
thanks to Anthony with his help in working on it.
-
This SF.net email is sponsored by: Splunk In
Jerone Young wrote:
> On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>>> This patch is an improved version of patches sent last week to enable
>>> the top level configuration file for cross compile. This currently
>>> allows x86 & x86-64 to cross compi
On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
> Jerone Young wrote:
> > This patch is an improved version of patches sent last week to enable
> > the top level configuration file for cross compile. This currently
> > allows x86 & x86-64 to cross compile. But will soon be sending patche
Anthony Liguori wrote:
> Izik Eidus wrote:
>>>
>>> That's not quite what I was wondering.
>>>
>>> When you do an madvise() in userspace, the result is that when that
>>> memory is accessed again, linux will demand-fault in a zero page and
>>> COW it appropriately. If we do madvise() on the VA re
Jerone Young wrote:
> This patch is an improved version of patches sent last week to enable
> the top level configuration file for cross compile. This currently
> allows x86 & x86-64 to cross compile. But will soon be sending patches
> for powerpc embedded once this is accepted. This patches to lat
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
Anthony Liguori wrote:
>
> I think it's just a matter of calling do_mmap() with the
> appropriate parameters. It looks likes there's some drivers call
> do_mmap() directly.
>
Izik Eidus wrote:
>>
>> That's not quite what I was wondering.
>>
>> When you do an madvise() in userspace, the result is that when that
>> memory is accessed again, linux will demand-fault in a zero page and
>> COW it appropriately. If we do madvise() on the VA representing
>> guest physical m
Anthony Liguori wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>> Anthony Liguori wrote:
I think it's just a matter of calling do_mmap() with the
appropriate parameters. It looks likes there's some drivers call
do_mmap() directly.
>>> yea, i think you right, this
Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
Anthony Liguori wrote:
> I've been playing around with these patches. If I do an
> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get
> the following bug. My knowledge of the
This patch is an improved version of patches sent last week to enable
the top level configuration file for cross compile. This currently
allows x86 & x86-64 to cross compile. But will soon be sending patches
for powerpc embedded once this is accepted. This patches to latest git
and is in git format
Izik Eidus wrote:
> Anthony Liguori wrote:
>> Izik Eidus wrote:
>>> Anthony Liguori wrote:
I've been playing around with these patches. If I do an
madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the
following bug. My knowledge of the mm is limited but since
Anthony Liguori wrote:
Izik Eidus wrote:
Anthony Liguori wrote:
I think it's just a matter of calling do_mmap() with the appropriate
parameters. It looks likes there's some drivers call do_mmap()
directly.
yea, i think you right, this is excellent idea!, when we will merge
the swapping t
Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> I've been playing around with these patches. If I do an
>>> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the
>>> following bug. My knowledge of the mm is limited but since
>>> madvise(MADV_DONTNEED) eff
The patch below removes the check for c->modrm_reg == 7 to detect the
invlpg instruction, as it was the case before before commit
aa38840d3d2e0a804e628077df8d8879b496d741. This fixes the boot of FreeBSD
on an AMD64 CPU.
It also moves the assignation of c->src.bytes after the test as it is
not ne
Izik Eidus wrote:
> Anthony Liguori wrote:
>> I've been playing around with these patches. If I do an
>> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the
>> following bug. My knowledge of the mm is limited but since
>> madvise(MADV_DONTNEED) effectively does a zap_page_range
Anthony Liguori wrote:
> I've been playing around with these patches. If I do an
> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the
> following bug. My knowledge of the mm is limited but since
> madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if
> we're
I've been playing around with these patches. If I do an
madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the
following bug. My knowledge of the mm is limited but since
madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if
we're lacking the necessary callback to
On 10/15/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> If we want to make the clocksource useful for Windows we need to go
> through the apic as that will allow the TPR to mask the interrupt when
> Windows isn't ready to receive it. However I don't know whether it is
> possible to integrate a paravi
On 10/15/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
> Gerd Hoffmann wrote:
> > With VT you can attempt to make that invisible to the guest using the
> > tsc offset field. Probably svm can do that too (didn't check docs
> > though). kvm-lite can't (what is the status btw?). Xen "solves" that
> >
On 10/15/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
>
> Host should know. Well, I hope. Dunno whenever one really can be sure
> in all cases given all the different CPUs and tsc implementations.
In the same way we can be sure about hardware for everything else:
Well... not being _quite_ sure ;
On 10/15/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gerd Hoffmann wrote:
> >
> >> 2) the TSC would have to be used as a clocksource. You don't know the
> >> frequency which is the first problem with using the TSC but some systems
> >> have a TSC that changes frequencies.
> >>
> >
> > Also note th
Hi,
On Monday 15 October 2007, you wrote:
> Jan Frey wrote:
> > So you can see AMD's "svm" is existent.
> > Host's kernel is 2.6.23.1, config file is attached.
> > KVM/Qemu sources I've tried include -37, -40, -45 and -46.
> >
> > When I run something like
> > qemu-system-x86_64 -m 384 -no-kvm
>
On 10/15/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
>
> >>> 1) the PIT is periodic. a PV timer can offer a one shot
> >timer which
> >>> enables dynticks.
> >>>
> >>
> >> Obviously people have figured out how to do dynticks on real x86
> >> hardware, so I don't accept this reason. :)
> >>
> >
> >U
On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
>
> What makes you think this is page-aligned?
Nothing.
> > + if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
> > + return;
>
> Here you're passing a virtual address across the guest/host interface,
> which i
On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > 2) the TSC would have to be used as a clocksource. You don't know the
> > frequency which is the first problem with using the TSC but some systems
> > have a TSC that changes frequencies. A PV time source gives you more
> > stable clock
On 10/12/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > * Measure the time it takes for a hypercall, and subtract this time
> > for calculating the expiry time for the timer event.
> >
>
> I don't think there's much point in trying to do stuff like this. The
> guest can be preempted at any
Glauber de Oliveira Costa wrote:
>>
>> It might be better to just rely on the in-kernel APIC to inject an
>> interrupt for the clock (via kvm_pic_set_irq()).
>>
>>
>
>
> After trying this option a little bit, it does not seemed worthwhile
> to me. But it might well have been due to some misund
> > +
> > +void __init kvmclock_init(void)
> > +{
> > +
> > + unsigned long shared_page = (unsigned long)&hv_clock;
> > + /*
> > + * If we can't use the paravirt clock, just go with
> > + * the usual timekeeping
> > + */
> > + if (!kvm_para_available() || no_kvmclock)
> >
Hollis Blanchard wrote:
>>
>> I'd think there is no reason for virtual timer to be PIT like, which
>> is mostly due to historic reason.
>>
>> If we need to make it close to native timer device, HPET is much
>> better than PIT for virtual time to look like.
>>
>
> Fine, so why do we need PV tim
Carsten Otte wrote:
> On s390, we've had an instruction...
Yes, quite ;)
J
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuratio
On Mon, 2007-10-15 at 12:04 +0800, Dong, Eddie wrote:
> >>> 1) the PIT is periodic. a PV timer can offer a one shot
> >timer which
> >>> enables dynticks.
> >>>
> >>
> >> Obviously people have figured out how to do dynticks on real x86
> >> hardware, so I don't accept this reason. :)
> >>
Hi,
It was some problem to ACPI interrupts delivering to the Windows guests.
This patch fixes this problem and enables the ACPI interrupts.
According to 82371AB spec. we need to reset the bit 0 of PIRQRCA register to
enable interrupt routing.
Note: This patch work fine with –no-kvm-ir
Avi Kivity wrote:
> Farkas Levente wrote:
>> Avi Kivity wrote:
>>
>>> Farkas Levente wrote:
>>>
>> we did a quick test against this version and it's turn out the smp
>> guests are still not working. even if we start only one linux guest
>> with
>> 4cpu on 4cpu host the guest
Hi,
I've been trying booting a knoppix Live CD KNOPPIX_V5.1.1CD-2007-01-04-EN.iso
without any success.
This is my setup:
- Fedora 7 with all the updates available up to today.
- kernel vmlinuz-2.6.22.9-91.fc7PAE
- kvm-45 and latest kvm-46
Boot fails because of a kernel panic
Call back trace:
- s
On Mon, 2007-10-15 at 11:13 +0200, Carsten Otte wrote:
> Izik Eidus wrote:
> > this patchs allow the guest not shadowed memory to be swapped out.
> This patch has greatly improved since I've read the swapping code last
> time. While not having time for a deep review, it looks very clean and
> san
Izik Eidus wrote:
> can you send me your kvmctl.c file so i will look at it?
> it is somewhat hard to me understand how you did the things that way
I'm trying to back a vm with memory coming from a file map, see patch
attached against kvm-46 (was also attached earlier in this thread).
I've made k
On Mon, 2007-10-15 at 13:15 +0200, Gerd Hoffmann wrote:
> Izik Eidus wrote:
> > On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
> >> Gerd Hoffmann wrote:
> >>
> >>> Something like this? (compiles, not tested yet).
> >> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
> >
>
Izik Eidus wrote:
> On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
>> Gerd Hoffmann wrote:
>>
>>> Something like this? (compiles, not tested yet).
>> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
>
> try use slot bigger bigger than 5 and smaller than 8
It doesn't come
On Mon, 2007-10-15 at 13:00 +0200, Gerd Hoffmann wrote:
> Gerd Hoffmann wrote:
>
> > Something like this? (compiles, not tested yet).
>
> Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
try use slot bigger bigger than 5 and smaller than 8
> cheers,
> Gerd
>
> ---
Gerd Hoffmann wrote:
> With VT you can attempt to make that invisible to the guest using the
> tsc offset field. Probably svm can do that too (didn't check docs
> though). kvm-lite can't (what is the status btw?). Xen "solves" that
> by not doing power management *evil grin*.
On s390, we've had
Gerd Hoffmann wrote:
> Something like this? (compiles, not tested yet).
Hmm, no-go, results in "kvm_create_vcpu: Cannot allocate memory".
cheers,
Gerd
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping throug
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>> Avi Kivity wrote:
>>
>>> We've now switched to allocating guest memory in userspace rather than
>>> in the kernel.
>>>
>> Hmm, a quick glimpse over kvmctl.h doesn't show an obvious way how to
>> use that. If I want to back vm memory with a file m
2007/10/15, Gerd Hoffmann <[EMAIL PROTECTED]>:
> Avi Kivity wrote:
> > Gerd Hoffmann wrote:
> >>
> >>> 2) the TSC would have to be used as a clocksource. You don't know the
> >>> frequency which is the first problem with using the TSC but some systems
> >>> have a TSC that changes frequencies.
> >
Avi Kivity wrote:
> Gerd Hoffmann wrote:
>>
>>> 2) the TSC would have to be used as a clocksource. You don't know the
>>> frequency which is the first problem with using the TSC but some systems
>>> have a TSC that changes frequencies.
>>>
>> Also note the tsc may stop ticking if the CPU
Avi Kivity wrote:
> Yang, Sheng wrote:
>> Yeah :)
>>
>> Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this
>> 'movnti' haven't been implement yet.
>>
>>
>
> So, it was using movnti for mmio into the nic registers?
Yeah, it's a mmio operation.
>
>
>> Avi Kivity wrote:
>>
>>>
Yang, Sheng wrote:
> Yeah :)
>
> Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this
> 'movnti' haven't been implement yet.
>
>
So, it was using movnti for mmio into the nic registers?
> Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
From 1b7892787f1b619a52e52275cf41
Yeah :)
Linux guest 2.6.16 x86_64 crashed when trying to get IP, for this
'movnti' haven't been implement yet.
Avi Kivity wrote:
> Yang, Sheng wrote:
>>> From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00
2001
>> From: Sheng Yang <[EMAIL PROTECTED]>
>> Date: Mon, 15 Oct 2007 14:24
Yang, Sheng wrote:
> >From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 2001
> From: Sheng Yang <[EMAIL PROTECTED]>
> Date: Mon, 15 Oct 2007 14:24:20 +0800
> Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg'
>
> Implement emulation of instruction:
> movnti m32/m64,
Laurent Vivier wrote:
> Add new-line at end of debug strings.
>
>
Applied, thanks. I always assumed ioapic_debug() added the \n by itself...
--
error compiling committee.c: too many arguments to function
-
This SF.net
Kevin Pedretti wrote:
> Hi,
>
> While booting a non-Linux OS under kvm-46, I noticed that reading
> APIC_TMCCT before initializing APIC_TDCR to something other than its
> boot time value would lead to a host kernel divide by zero exception.
> It's due to apic->timer.divide_count being set to 0 at b
>From 1b7892787f1b619a52e52275cf41248f1131d1b6 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 14:24:20 +0800
Subject: [PATCH] KVM: x86 emulator: implement 'movnti mem, reg'
Implement emulation of instruction:
movnti m32/m64, r32/r64
opcode: 0x0f 0xc3
John Clemens wrote:
> Not much detail here but I'll post all I can.
>
> KVM-46 (from tarball, using kvm-46 modules), ubuntu gutsy
> 2.6.22-14-generic amd64, Turion X2 with SVM, 1GB total memory on
> laptop.
>
> Was in the middle of an windows xp pro sp2 install using this command
> line:
>
> su
Zhang, Xiantao wrote:
>
>>> - u64 ia32_misc_enable_msr;
>>>
>>> struct kvm_mmu mmu;
>>>
>>>
>> mmu
>>
>
> About mmu, i am not sure about this. IA64 only need kvm module to
> allocate and free memory for guests. Most functions related to mmu are
> useless for IA64. If we put them
Izik Eidus wrote:
> this patchs allow the guest not shadowed memory to be swapped out.
This patch has greatly improved since I've read the swapping code last
time. While not having time for a deep review, it looks very clean and
sane to me when scrolling over.
---
Jan Frey wrote:
> So you can see AMD's "svm" is existent.
> Host's kernel is 2.6.23.1, config file is attached.
> KVM/Qemu sources I've tried include -37, -40, -45 and -46.
>
> When I run something like
> qemu-system-x86_64 -m 384 -no-kvm
>
> The virtual machine boots and everything works fine (ex
Dong, Eddie wrote:
>> N+1, for me is that synchronous device emulation (like pio and mmio)
>> happens in in the vcpu thread and asynchronous device emulation
>> (handling signals in qemu, performing dma, and injecting interrupts)
>> happens in the device thread. This minimizes context switching an
Gerd Hoffmann wrote:
>
>> 2) the TSC would have to be used as a clocksource. You don't know the
>> frequency which is the first problem with using the TSC but some systems
>> have a TSC that changes frequencies.
>>
>
> Also note the tsc may stop ticking if the CPU goes sleep in C3, which
Zhao Forrest wrote:
>
> When running KVM(kvm.rtl) and xen-HVM(xen.um) on the same machine, I
> feel that the guest OS on top of KVM is much faster responsive than
> the one on top of xen-HVM.
> But this test result showed that xen-HVM is more responsive than KVM.
> Weird. I onced tried KVM-36 and x
James Dykman wrote:
> Dor,
>
> I ran some netperf tests with your PV
> virtio drivers, along with some Xen PV cases
> and a few others for comparison. I thought you
> (and the list) might be interested in the numbers.
>
> I am going to start looking for bottlenecks, unless
> you need help with th
Hi,
> 2) the TSC would have to be used as a clocksource. You don't know the
> frequency which is the first problem with using the TSC but some systems
> have a TSC that changes frequencies.
Also note the tsc may stop ticking if the CPU goes sleep in C3, which
IMHO makes the tsc almost useles
Carsten Otte wrote:
>
>
> Avi Kivity wrote:
>> We need to distinguish between x86 specific (only x86 has this) and s390
>> special (everyone has it except s390). In the latter case it should
>> still be in common code to avoid duplication, with a guard to disable
>> compilation on s390.
>>
>> KVM_S
Avi Kivity wrote:
> Zhang, Xiantao wrote:
[in struct kvm_vcpu]
>> int interrupt_window_open;
> arch specific, though maybe it's close enough to generic
I thought about this field for a while. What we really want, is that
the common code can figure wheter or not it is a good idea to send an
Carsten Otte wrote:
>
> Avi Kivity wrote:
>> We need to distinguish between x86 specific (only x86 has this) and s390
>> special (everyone has it except s390). In the latter case it should
>> still be in common code to avoid duplication, with a guard to disable
>> compilation on s390.
>>
>> KVM_SE
Avi Kivity wrote:
> We need to distinguish between x86 specific (only x86 has this) and s390
> special (everyone has it except s390). In the latter case it should
> still be in common code to avoid duplication, with a guard to disable
> compilation on s390.
>
> KVM_SET_MEMORY_REGION is in theory
Anthony Liguori wrote:
> So does MADV_REMOVE remove the backing page but still allow for memory
> to be faulted in? That is, after calling MADV_REMOVE, there's no
> guarantee that the contents of a give VA range will remain the same (but
> it won't SEGV the app if it accesses that memory)?
>
>
WATCH KGLJ TRADE ON
MONDAY OCTOBER 15, 2007
WE ARE 100% CONFIDENT THAT THIS ONE WILL BE THE RUNNER OF THE YEAR!
Name: Kingslake Energy, Inc.
Symbol: KGLJ
Price: $1.51
5-D Target: $4
Rating: Agressive Buy
ADD KGLJ TO YOUR RADAR ON MONDAY OCTOBER 15!
RIDE THE WAVE LIKE A SURFER! END UP ON TOP!
DON
77 matches
Mail list logo
