Glauber de Oliveira Costa wrote:
>>>
>> Here you're passing a virtual address across the guest/host interface,
>> which is something we've previously agreed is bad.
>>
> And that's the reason for the "nothing". It was just the easier way,
> and I'm not aware of any discussion in which i
Glauber de Oliveira Costa wrote:
Obviously people have figured out how to do dynticks on real x86
hardware, so I don't accept this reason. :)
>>> Using more advanced timers like the HPET.
>>>
>>>
>> I'd think there is no reason for virtual timer to be PIT li
Glauber de Oliveira Costa wrote:
> 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 fo
Glauber de Oliveira Costa wrote:
> 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 whe
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
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
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_
Glauber de Oliveira Costa wrote:
> Well, my previous understanding was that if the CPU marks the tsc as
> stable, it _won't_ stop even in C3, and it was done this way exactly
> to make sure there are a stable source for timing.
Other way around: Kernel can mark the TSC unstable if it figures it
d
Hollis Blanchard wrote:
> That's a good point, but does PIT/HPET emulation show up as a hot spot
> in any profiles? I think keeping the hypercall API as small as feasible
> is a desirable design goal.
pit probably doesn't due to being rarely updated. For hpet I'd expect
it showing up much more.
+ case KVM_HCALL_SET_ALARM: {
+ ktime_t kt;
+ kt = ktime_add_ns(ktime_get_real(), a0);
This one will cause accumulated time shift. a0 is the delta time
when the guest calculate.
+ hrtimer_start(&vcpu->oneshooter, kt, HRTIMER_MODE_ABS);
+
Avi Kivity wrote:
> 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 minimi
Greetings,
kvm's configure calls qemu's configure with --enable-alsa, making the
existence and use of alsa a dependency; with the import of the latest CVS
qemu, a similar implicit dependency has been added for gnutls (required for
TLS support for qemu's vnc server).
the following proposed patch (
Aurelien Jarno wrote:
> 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.byt
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 r
Anthony Liguori wrote:
> I'm curious why --enable-alsa is here in the first place. QEMU will use
> SDL audio by default. Perhaps Avi can shed light on why added in the
> first place?
>
seemed like a good idea at the time. It's not like I actually
know what goes on in the qemu sound emula
Izik Eidus wrote:
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 74b427f..0b12a98 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -68,6 +68,7 @@
> * vcpu->requests bit members
> */
> #define KVM_TLB_FLUSH 0
> +#define VMX_INJECT_RMODE_IRQ 1
>
> /*
> * Addre
Hollis Blanchard wrote:
> That's a good point, but does PIT/HPET emulation show up as a hot spot
> in any profiles? I think keeping the hypercall API as small as feasible
> is a desirable design goal.
>
At the moment I think not. Even a dyntick kernel would only require a
few thousands exits
Avi Kivity a écrit :
> Aurelien Jarno wrote:
>> 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
Glauber de Oliveira Costa wrote:
> I think I'll stick to two fields then, with u64 for seconds and nanoseconds.
> Or would it just be better to use a u64 nanoseconds field?
>
> A _lot_ of time should have passed before such counter overflows. So
> having two is possibly overkill
u64 nanoseconds lo
Avi Kivity wrote:
> 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 f
Jerone Young wrote:
> 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
[EMAIL PROTECTED] wrote:
> Hollis Blanchard wrote:
>> That's a good point, but does PIT/HPET emulation show up as a hot
>> spot in any profiles? I think keeping the hypercall API as small as
>> feasible is a desirable design goal.
>>
>
> At the moment I think not. Even a dyntick kernel would on
[EMAIL PROTECTED] wrote:
>>
>> I meant the mmu is x86 specific.
>
> Sorry for misunderstanding. Should we move out the code logic related
> to mmu from kvm_main.c , and put them as arch-specific code ?:)
>
The main issue is X86 is implementing shadow page table for virtual
MMU, but IA64 implem
Aurelien Jarno wrote:
> Avi Kivity a écrit :
>
>> Aurelien Jarno wrote:
>>
>>> 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
Zhang, Xiantao wrote:
>
>>> 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 as common, Maybe we have to
>>> define some blank functions.
>>>
>>>
>>>
>> I meant
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> 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)
hap
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>
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 as common, Maybe we have to
define some blank functions.
Gerd Hoffmann wrote:
> Hollis Blanchard wrote:
>
>> That's a good point, but does PIT/HPET emulation show up as a hot spot
>> in any profiles? I think keeping the hypercall API as small as feasible
>> is a desirable design goal.
>>
>
> pit probably doesn't due to being rarely updated. For
Jerone Young wrote:
> This new patch
btw, if it's an updated patch, don't put [RESEND] in there, it confuses
me. Put in v2, v3, etc. so I know it's something new.
A [RESEND] is for when I've dropped a patch without comment (which
should not happen normally).
--
error compiling committee.c:
Zhang, Xiantao wrote:
> Avi Kivity wrote:
>
>> Zhang, Xiantao wrote:
>>
> 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 as common, Maybe we have to
>>
Carlo Marcelo Arenas Belon wrote:
> Greetings,
>
> kvm's configure calls qemu's configure with --enable-alsa, making the
> existence and use of alsa a dependency; with the import of the latest CVS
> qemu, a similar implicit dependency has been added for gnutls (required for
> TLS support for qemu's
Jan Frey wrote:
>> Can you set up netconsole or serial console on that machine and grab the
>> kernel output?
>>
>
> Currently I don't have really much time.. could you point me to some guide
> or manual about what to do exactly? I'll try to do so in a few days..
>
>
Netconsole is easiest
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>>
>
>>> Yes. But from what I looked, there isn't much mmu code in
>>> kvm_main.c, only calls to mmu code.
>>>
>>
>> I mean this too. Maybe IA64 can define some blank fucntions called
>> in kvm_main.c.
>>
>>
>
> You will
On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote:
> Greetings,
>
> kvm's configure calls qemu's configure with --enable-alsa, making the
> existence and use of alsa a dependency; with the import of the latest CVS
> qemu, a similar implicit dependency has been added for gn
On Tue, Oct 16, 2007 at 02:39:30PM +0100, Daniel P. Berrange wrote:
> On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote:
> > I am curious if the approach taken for alsa (which is the one that fits what
> > qemu's configure allows for this case) is acceptable or not, as it w
Carlo Marcelo Arenas Belon wrote:
>
>> It seems like rather
>> a bad idea to suddenly switch the configure script defaults in the way you
>> suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
>> in the top of configure, and then have the flag toggle it to off.
>>
>
>
Anthony Liguori wrote:
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
Hello Eddie,
Am Montag 15 Oktober 2007 06:13:44 schrieb Dong, Eddie:
> >That 0.1% kills me though. do you mean, that every 1 second, 1
> >will be 1ms
> >off? And for every second thereafter, leaving me with 1 second
> >drift after
> >only 1000 seconds?
>
> Oh, that is not my intension :-(
> I jus
Izik Eidus wrote:
> Anthony Liguori wrote:
>> 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
Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
>
>>
>>
>>> It seems like rather
>>> a bad idea to suddenly switch the configure script defaults in the way you
>>> suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
>>> in the top of configure, and then have t
Jerone Young wrote:
> On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
>
>
>>> +fi
>>> +
>>> +qemudir=`pwd`/qemu
>>> +
>>> +#configure user dir
>>> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
>>> + $user_opts --arch="$arch")
>>> +(cd qemu; ./conf
On Tue, Oct 16, 2007 at 04:20:37PM +0200, Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
> >
> >>It seems like rather
> >>a bad idea to suddenly switch the configure script defaults in the way
> >>you suggest for alsa. It really wouldn't be much harder to set
> >>enable_alsa=1
> >>in the
Carlo Marcelo Arenas Belon wrote:
>
>> If so I prefer being closer to qemu as you suggest.
>>
>
> you mean closer as on using the same syntax, or closer as on avoiding changing
> qemu unless absolutely needed?
>
>
Both.
--
error compiling committee.c: too many arguments to function
---
Carlo Marcelo Arenas Belon wrote:
> On Tue, Oct 16, 2007 at 04:20:37PM +0200, Avi Kivity wrote:
>
>> Carlo Marcelo Arenas Belon wrote:
>>
>>>
>>>
It seems like rather
a bad idea to suddenly switch the configure script defaults in the way
you suggest for alsa. It rea
高 级 文 秘 职 业 化 训 练
中 国・上 海・2007 年 11月2-3日
中 国・北 京・2007 年 11月9-10日
中 国・深 圳・2007 年 10月20-21日
━━━
● 授 课 对 象
企业中层行政管理干部和文秘工作人员，包括办公室主任、行政部经理、董事长秘书、
总经理秘书、行政助理、行政主管、行政部门文员等
⊙主 办单
Hi Avi,
Attached is the patch to implement the emulation of instruction
inc : opcodes 0x40-0x47
&
dec : opcodes 0x48-0x4f
Please Apply.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
Hi Avi,
I was trying to avoid vm86 mode completely, by using emulation for
all the real mode code emulation. It is doing better than vm86 mode, but
I am seeing one issue with this approch.
The emulator is failing due to this code. Seems like the execution
need to go back to qemu to finish so
Avi Kivity wrote:
> 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 w
Bugs item #1814637, was opened at 2007-10-16 20:39
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=1814637&group_id=180599
Please note that this message will contain a full copy
On Tue, 2007-10-16 at 11:59 +0200, Avi Kivity wrote:
> Jerone Young wrote:
> > 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
On Tue, 2007-10-16 at 09:59 -0500, Anthony Liguori wrote:
> Jerone Young wrote:
> > On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
> >
> >
> >>> +fi
> >>> +
> >>> +qemudir=`pwd`/qemu
> >>> +
> >>> +#configure user dir
> >>> +(cd user; ./configure --prefix="$prefix" --kerneldir="$libk
Jerone Young wrote:
>
>>> while [[ "$1" = -* ]]; do
>>> opt="$1"; shift
>>> @@ -48,11 +45,17 @@ while [[ "$1" = -* ]]; do
>>> want_module=
>>> ;;
>>> --qemu-cc)
>>> - qemu_cc="$arg"
>>> + cc="$arg"
>>>
>>>
>> This forces everything to be compiled w
Anthony Liguori wrote:
>>> What I don't understand, is how we can have something like
>>> mmu_unshadow() called automatically when an mmap() is initiated from
>>> userspace. We could just add an ioctl() to do it from userspace but
>>> I think it would be nicer if it Just Worked.
>>>
>>
>> Behol
Jerone Young wrote:
> On Tue, 2007-10-16 at 09:59 -0500, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>>> On Mon, 2007-10-15 at 15:13 -0500, Anthony Liguori wrote:
>>>
>>>
>>>
> +fi
> +
> +qemudir=`pwd`/qemu
> +
> +#configure user dir
> +(cd user; ./c
Based on comments I've added the ability to separately add a compiler
for qemu. CFLAGS & LDFLAGS for qemu now have an option. I've also added
information back to the help screen.
I had not thought much about how the kernel/ directory takes in the
config.mak that is created. Currently I am not usi
Nitin A Kamble wrote:
> Hi Avi,
>I was trying to avoid vm86 mode completely, by using emulation for
> all the real mode code emulation. It is doing better than vm86 mode,
Why do you think it is better? I would have thought that vm86 is much
faster.
I thought of doing it this way:
- try to
Nitin A Kamble wrote:
> Hi Avi,
>Attached is the patch to implement the emulation of instruction
>
> inc : opcodes 0x40-0x47
> &
> dec : opcodes 0x48-0x4f
>
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
On Tue, 2007-10-16 at 13:12 -0700, Avi Kivity wrote:
> Why do you think it is better? I would have thought that vm86 is much
> faster.
>
I am seeing execution going to strange places in vm86 mode. That issue
is not coming in the emulation.
> I thought of doing it this way:
>
> - try to run nor
This patch takes feedback from Anthony Liguouri.
- remove --cc option added in v4 of patch (keep old behavior)
- do not specify cc= everytime on the qemu configuration line, this
allows qemu to autodetect gcc 3.x
This simplifies the patch more. While preserving behavior.
Signed-off-by: Jerone You
Jerone Young wrote:
> This patch takes feedback from Anthony Liguouri.
> - remove --cc option added in v4 of patch (keep old behavior)
> - do not specify cc= everytime on the qemu configuration line, this
> allows qemu to autodetect gcc 3.x
>
> This simplifies the patch more. While preserving behav
Hi Avi,
Attached is the patch implementing these eflags manipulating
instructions:
cmc, clc, cli, sti
opcodes: 0xf5, 0xf8, 0xfa, 0xfb
please Apply.
--
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
--
Avi Kivity wrote:
>>
>> It can in theory, but do we have the real usage for
>> qemu_system_reset which is the only caller of
>> KERNEL RESET.
>>
>>
>
> Well, if the guest resets itself, then reset is called from the vcpu
> thread. If we reset from the qemu monitor, it can be called from a
> no
Not quit understand the following code. If we just set
a vcpu request bits w/o real irq injection, we can't resume
to guest? Othrewise, the guest is in interruptable state and can
see irq pending, but it doesn't get the interrupt.
Something missing?
thx,eddie
--- a/drivers/kvm/vmx.c
+++ b/dri
Kay Hayen wrote:
> Hello Eddie,
>
> Am Montag 15 Oktober 2007 06:13:44 schrieb Dong, Eddie:
>>> That 0.1% kills me though. do you mean, that every 1 second, 1
>>> will be 1ms
>>> off? And for every second thereafter, leaving me with 1 second
>>> drift after only 1000 seconds?
>>
>> Oh, that is no
64 matches
Mail list logo
