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 real mode.
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 it was agreed
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 like, which
is mostly due to
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 for
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 whether it
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
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)
+ 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 minimizes context
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?
shrug seemed like a good idea at the time. It's not like I actually
know what goes on in the qemu sound
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
/*
* Address types:
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 per
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 the
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 looks
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 for IA64. If we put them as common,
[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 only require
[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 implement
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
on an AMD64
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)
happens in the device
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.
I meant the mmu
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 hpet I'd
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
define some blank
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 vnc
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 (no need
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 need mmu_unload(), reload(),
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 gnutls
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 will
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.
ok, but if
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 just put a
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 can send out all of
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 the flag toggle it
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 top of
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 really wouldn't be much
高 级 文 秘 职 业 化 训 练
中 国・上 海・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
-
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 we do madvise() on the VA
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=detailatid=893831aid=1814637group_id=180599
Please note that this message will contain a full copy of
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=$libkvm_kerneldir
\
+
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 with $cc, not just qemu? Or is
the
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
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 normally
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
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 behavior.
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
non-vcpu thread.
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
+++
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 not my intension :-(
52 matches
Mail list logo
