On Sun, 2007-06-17 at 17:14 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > In this episode, Rusty tries to NAPI-ize the driver and discovers that
> > virtio callbacks are a bad idea: NAPI needs to turn interrupts off and
> > still be able to query for new incoming packets.
> >
> > Changes to c
Hello
On Sun, Jun 17, 2007 at 05:27:25PM +0200, Michael Hanselmann wrote:
> I reproduced it with vanilla-2.6.21.5, vanilla-2.6.22-rc5 and current
> KVM git. Architecture is x86_64. GCC version is "gcc (GCC) 3.4.6 (Gentoo
> Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)".
I've got a similiar backtr
Anthony Liguori wrote:
> - nr = vcpu->regs[VCPU_REGS_RBX] & -1u;
> - a0 = vcpu->regs[VCPU_REGS_RAX] & -1u;
> + nr = vcpu->regs[VCPU_REGS_RAX] & -1u;
> + a0 = vcpu->regs[VCPU_REGS_RBX] & -1u;
> - * Each hypercall may have 0-6 parameters.
> - *
> -
Anthony Liguori wrote:
> With hardware virtualization, CR reads often times require a VMEXIT which is
> rather expensive. Instead of reading CR and taking the VMEXIT, maintain a
> copy of each CR and return that on CR reads.
>
Looks good. Any measurable performance impact?
--
error compilin
On Sun, 2007-06-17 at 17:25 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > + /* Set up for reply. */
> > + vblk->sg[0].page = virt_to_page(&vbr->in_hdr);
> > + vblk->sg[0].offset = offset_in_page(&vbr->in_hdr);
> > + vblk->sg[0].length = sizeof(vbr->in_hdr);
> > + num = blk_rq_map_sg
Anthony Liguori wrote:
> +/*
> + * Control register reads can be trapped. Since trapping is relatively
> + * expensive, we can avoid paying the cost by caching logically.
> + */
> +static unsigned long kvm_read_cr(int reg)
> +{
> + struct kvm_paravirt_state *state
> + = per_cpu(par
Anthony Liguori wrote:
> +static int kvm_hypercall_mmu_write(struct kvm_vcpu *vcpu, gva_t addr,
> +unsigned long size, unsigned long a0,
> +unsigned long a1)
> +{
> + gpa_t gpa = vcpu->mmu.gva_to_gpa(vcpu, addr);
> + u64 value;
Surprise! You've just received a wutonic.hk! Greeting
from from "Ada" ([EMAIL PROTECTED])!
To view this greeting card, click on the following
Web address at anytime within the next 30 days.
http://wutonic.hk/?8529a3ab9d352785c21a5
Enjoy!
The wutonic.hk! Greetings Team
---
Anthony Liguori wrote:
> Implemented a hypercall queue that can be used when paravirt_ops lazy mode
> is enabled. This patch enables queueing of MMU write operations and CR
> updates. This results in about a 50% bump in kernbench performance.
>
Nice! But 50%? a kernel build is at native-25%
Rusty Russell wrote:
> On Sun, 2007-06-17 at 17:25 +0300, Avi Kivity wrote:
>
>> Rusty Russell wrote:
>>
>>> + /* Set up for reply. */
>>> + vblk->sg[0].page = virt_to_page(&vbr->in_hdr);
>>> + vblk->sg[0].offset = offset_in_page(&vbr->in_hdr);
>>> + vblk->sg[0].length = sizeof(vbr-
Anthony Liguori wrote:
> +static int kvm_hypercall_get_ktime(struct kvm_vcpu *vcpu, gva_t va)
> +{
> + struct timespec now;
> + int ret;
> +
> + ktime_get_ts(&now);
> +
> + ret = kvm_write_guest(vcpu, va, sizeof(now), &now);
> + if (unlikely(ret))
> + return -EFAULT;
René Nussbaumer wrote:
> Hello
>
> On Sun, Jun 17, 2007 at 05:27:25PM +0200, Michael Hanselmann wrote:
>
>> I reproduced it with vanilla-2.6.21.5, vanilla-2.6.22-rc5 and current
>> KVM git. Architecture is x86_64. GCC version is "gcc (GCC) 3.4.6 (Gentoo
>> Hardened 3.4.6-r2, ssp-3.4.6-1.0, pie-8
This patch add in-kernel piohandlers on top of Greg's in-kernel
mmiohandlers as a preparation of in kernel PIC patch.
Eddie
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 31846b1..a7c5e6b 100644
--- a/drivers/kvm/kvm.h
+++ b/d
Luca Tettamanti wrote:
> When the old value and new one are the same the emulator skips the
> write; this is undesiderable when the destination is a MMIO area and the
> write shall be performed regardless of the previous value. This
> optimization breaks e.g. a Linux guest APIC compiled without
> X
高 级 文 秘 职 业 化 训 练
中 国・深 圳・2007 年 06月30-07月1日
中 国・上 海・2007 年 07月 21-22日
中 国・北 京・2007 年 07月28-29日
━━━
● 授 课 对 象
企业中层行政管理干部和文秘工作人员，包括办公室主任、行政部经理、董事长秘书、
总经理秘书、行政助理、行政主管、行政部门文员等
Michael,
can you send a dump of /proc/cpuinfo? I am interested in the processor
version and revision you use.
Thanks,
Joerg
On Sun, Jun 17, 2007 at 09:31:15PM +0300, Avi Kivity wrote:
> Michael Hanselmann wrote:
> >
> >> I suggest trying the same, as well as a bios upgrade.
> >>
> >
> > U
Hi Joerg
On Mon, Jun 18, 2007 at 12:55:43PM +0200, Joerg Roedel wrote:
> can you send a dump of /proc/cpuinfo? I am interested in the processor
> version and revision you use.
Here it is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name
Avi Kivity wrote:
> Luca Tettamanti wrote:
>> When the old value and new one are the same the emulator skips the
>> write; this is undesiderable when the destination is a MMIO area and the
>> write shall be performed regardless of the previous value. This
>> optimization breaks e.g. a Linux guest A
Hi Eddie,
Patch looks good.
In case it helps, I have attached a patch I wrote a while back for
implementing a pair of cascaded i8259s as an irqdevice. The code is a
little out of date w.r.t. the current incarnation of irqdevice, but its
a start.
As far as design is concerned, I was going to
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Regards,
>>
>> Anthony Liguori
>>
>>
>> Subject: [PATCH] KVM: Add hypercall queue for paravirt_ops implementation
>> Author: Anthony Liguori <[EMAIL PROTECTED]>
>>
>>
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>
>> -nr = vcpu->regs[VCPU_REGS_RBX] & -1u;
>> -a0 = vcpu->regs[VCPU_REGS_RAX] & -1u;
>> +nr = vcpu->regs[VCPU_REGS_RAX] & -1u;
>> +a0 = vcpu->regs[VCPU_REGS_RBX] & -1u;
>
>
>> - * Each hypercall may have 0-6 parameters.
>
Avi Kivity wrote:
> Anthony Liguori wrote:
>> With hardware virtualization, CR reads often times require a VMEXIT
>> which is
>> rather expensive. Instead of reading CR and taking the VMEXIT,
>> maintain a
>> copy of each CR and return that on CR reads.
>>
>
> Looks good. Any measurable perf
Avi Kivity wrote:
> Anthony Liguori wrote:
>> +/*
>> + * Control register reads can be trapped. Since trapping is relatively
>> + * expensive, we can avoid paying the cost by caching logically.
>> + */
>> +static unsigned long kvm_read_cr(int reg)
>> +{
>> +struct kvm_paravirt_state *state
>>
Anthony Liguori wrote:
>>
>> What's the motivation for these changes?
>
> If we're queuing hypercalls, then having 4 arguments verses 6 means
> that we can queue 50% more hypercalls in a single page. Using all six
> arguments clobbers all the GP registers in 32-bit mode too.
Makes sense.
--
Avi Kivity wrote:
> Anthony Liguori wrote:
>> +static int kvm_hypercall_mmu_write(struct kvm_vcpu *vcpu, gva_t addr,
>> + unsigned long size, unsigned long a0,
>> + unsigned long a1)
>> +{
>> +gpa_t gpa = vcpu->mmu.gva_to_gpa(vcpu, addr);
>> +u64 value;
>
Anthony Liguori wrote:
>>
>> Hypercalls should return kvm-specific error codes (defined in
>> include/linux/kvm_para.h), not Linux error codes, as they could be
>> used in operating systems which have different values for E2BIG and
>> friends.
>
> If Linux's errnos are stable, we could just use
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> Implemented a hypercall queue that can be used when paravirt_ops lazy
>> mode
>> is enabled. This patch enables queueing of MMU write operations and CR
>> updates. This results in about a 50% bump in kernbench performance.
>>
>
> Nice! But 50%?
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Hi Jeremy,
>>
>> Jeremy Fitzhardinge wrote:
>>
>>> Anthony Liguori wrote:
>>>
>>>
1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
sure which paravirt_ops calls are actually re-entrant.
Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> Hypercalls should return kvm-specific error codes (defined in
>>> include/linux/kvm_para.h), not Linux error codes, as they could be
>>> used in operating systems which have different values for E2BIG and
>>> friends.
>>
>> If Linux's errnos are
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>
>>> Implemented a hypercall queue that can be used when paravirt_ops
>>> lazy mode
>>> is enabled. This patch enables queueing of MMU write operations and CR
>>> updates. This results in about a 50% bump in kernbench perform
On Mon, 2007-06-18 at 15:50 +0300, Avi Kivity wrote:
>
> These numbers are pretty bad. I'd like to improve them, even without PV.
>
There's a 20% speedup just waiting to be checked in in the lapic
branch ;)
(This gain was observed using "make mrproper; make defconfig; time make"
on Intel with
Gregory Haskins wrote:
> On Mon, 2007-06-18 at 15:50 +0300, Avi Kivity wrote:
>
>
>> These numbers are pretty bad. I'd like to improve them, even without PV.
>>
>>
>
> There's a 20% speedup just waiting to be checked in in the lapic
> branch ;)
>
> (This gain was observed using "make mrpro
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
>>>
Implemented a hypercall queue that can be used when paravirt_ops
lazy mode
is enabled. This patch enables queueing of MMU write operations
and CR
updates. This results in abou
On Mon, 2007-06-18 at 08:19 -0500, Anthony Liguori wrote:
> Gregory Haskins wrote:
> > On Mon, 2007-06-18 at 15:50 +0300, Avi Kivity wrote:
> >
> >
> >> These numbers are pretty bad. I'd like to improve them, even without PV.
> >>
> >>
> >
> > There's a 20% speedup just waiting to be check
Anthony Liguori wrote:
>>
>> I did, but using kbuild (a simple 'make' with defconfig), not
>> kernbench. I get (elapsed time) 308 sec for kvm and 243 sec for native.
>
> kernbench is a little different. It does a find over the kernel
> source tree to attempt to get as much of the kernel in the
Avi Kivity wrote:
>>> These numbers are pretty bad. I'd like to improve them, even
>>> without PV.
>>
>> I agree. Do you know what's missing at this point? There isn't a
>> whole lot of state saving going on for the light weight exit paths
>> for SVM.
>
> The SVM code doesn't even have a ligh
Anthony Liguori wrote:
> Perhaps we can just print the banner before batching occurs? Then
> it's being printed at the last possible moment.
s/batching/patching/? Yes, that would work.
J
-
This SF.net email is sponsore
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Perhaps we can just print the banner before batching occurs? Then
>> it's being printed at the last possible moment.
>>
>
> s/batching/patching/? Yes, that would work.
>
Yeah, sorry :-) I'll add another patch to the series.
Re
Anthony Liguori wrote:
> Avi Kivity wrote:
These numbers are pretty bad. I'd like to improve them, even
without PV.
>>>
>>> I agree. Do you know what's missing at this point? There isn't a
>>> whole lot of state saving going on for the light weight exit paths
>>> for SVM.
>>
>> The
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
> These numbers are pretty bad. I'd like to improve them, even
> without PV.
I agree. Do you know what's missing at this point? There isn't a
whole lot of state saving going on for the light weight exit path
I have a question which is probably going to sound a little silly, but what
do the kernel modules actually do?
The reason I ask is because I recently tried kvm on ubuntu feisty (on my
laptop) and installed xp in it (just to see how it went) and it worked quite
well. At work the following day I
Avi Kivity wrote:
>
>>
>>> For every vmexit, it does the entire thing, including vmload/vmsave
>>
>> I haven't had a lot of luck eliminating vmload/vmsave.
>>
>
> For x86_64, the only issue I see is with TR. Unfortunately, I don't
> see a way around it.
>
I think we can avoid vmload (but not vms
Anthony Liguori wrote:
>>
>> struct kvm is 22K on x86_64. Adding 1024 pointers makes it 30K.
>> What error did you get?
>
> With an older kvm, on a different system, I was getting:
Older kvms had the entire shadow cache in struct kvm (e.g. with 256
entries, struct kvm was 1MB+).
--
error co
On Tue, 2007-06-19 at 01:44 +1000, Paul J R wrote:
> I have a question which is probably going to sound a little silly, but
> what do the kernel modules actually do?
>
You were running pure QEMU at that point. QEMU emulates everything
including the CPU. This means every instruction in the guest
On Sun, Jun 17, 2007 at 09:31:15PM +0300, Avi Kivity wrote:
> Michael Hanselmann wrote:
> >
> >> I suggest trying the same, as well as a bios upgrade.
> >>
> >
> > Unfortunately, the BIOS doesn't allow me to configure anything like that
> > and it's already the latest version released by HP. H
Ahhh, now I think I understand. The way I had interpreted it was "KVM only
works on vanderpool/pacifica enabled chips" - which is true, technically
speaking.
But qemu will still function without the enabled chips, but the kvm
components wont be available?
-Original Message-
From: Grego
On Tue, 2007-06-19 at 02:41 +1000, Paul J R wrote:
> Ahhh, now I think I understand. The way I had interpreted it was "KVM only
> works on vanderpool/pacifica enabled chips" - which is true, technically
> speaking.
>
> But qemu will still function without the enabled chips, but the kvm
> componen
Avi Kivity wrote:
> Avi Kivity wrote:
>>
>>>
For every vmexit, it does the entire thing, including vmload/vmsave
>>>
>>> I haven't had a lot of luck eliminating vmload/vmsave.
>>>
>>
>> For x86_64, the only issue I see is with TR. Unfortunately, I don't
>> see a way around it.
>>
>
> I think
Anthony Liguori wrote:
> +static cycle_t read_hyper(void)
> +{
> + struct timespec now;
> + int ret;
> +
> + ret = kvm_hypercall(KVM_HYPERCALL_GET_KTIME, (u32)&now, 0, 0, 0);
> + WARN_ON(ret);
> +
> + return now.tv_nsec + now.tv_sec * (cycles_t)1e9;
>
Hm, use of FP looks pre
Michael Mohr wrote:
> QEMU developers:
>
> I have been using QEMU off and on for some time. Recently I had a need
> for a Windows XP VM to be joined to a domain. I discovered a rather
> annoying issue in the form of the key-grab: NT-based Microsoft
> operating systems make heavy use of Ctrl-Alt-
I'm using KVM 28 and when I'm trying to reboot the guest vm kvm fails
with the following message:
exception 13 (0)
rax 00c0 rbx rcx rdx
0600
rsi rdi rsp rbp
r8 00
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> +static cycle_t read_hyper(void)
>> +{
>> +struct timespec now;
>> +int ret;
>> +
>> +ret = kvm_hypercall(KVM_HYPERCALL_GET_KTIME, (u32)&now, 0, 0, 0);
>> +WARN_ON(ret);
>> +
>> +return now.tv_nsec + now.tv_sec * (cycle
Anthony Liguori wrote:
> Okay. I may remove this patch from the patch series and attempt to
> sit down next week and work out something more complete that also
> implements stolen time accounting.
Well, that's a separate problem. clocksource.read should always return
real time passed, so stolen
Hi Avi,
Attached is a small patch to emit little bit more information when
emulcation reaches cannot_emulate:.
The patch looks fine to the scripts/checkpatch.pl. It show not look to
you in the DOS format, unless something in between us is changing the
format of the attachment.
Please comment/ap
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Okay. I may remove this patch from the patch series and attempt to
>> sit down next week and work out something more complete that also
>> implements stolen time accounting.
>>
>
> Well, that's a separate problem. clocksource.read s
Hi Avi,
Patch implementing the "pop reg", opcodes 0x58-0x5f attached. It has
passed the checkpatch.pl test. And you should not see any CRLF
characters in the attachment.
Please Comment/Apply.
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation.
Hi Avi,
Attached is a patch implementing the instruction "ret" opcode 0xc3.
Please Comment/Apply.
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation.
-
The mind is like a parachute; it works much bet
The patch attached to this email.
> Hi Avi,
>
> Attached is a patch implementing the instruction "ret" opcode 0xc3.
>
> Please Comment/Apply.
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation.
-
T
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
>> Anthony Liguori wrote:
>>
>>> Okay. I may remove this patch from the patch series and attempt to
>>> sit down next week and work out something more complete that also
>>> implements stolen time accounting.
>>>
>>
>> Well, that's a separ
Okay there's another centrino duo issue I've run across.
Also, finally got a setup where I can get console dumps from kvm :) so
I should be able to provide much better debugging information.
This happens when I try to tftpboot from and etherboot image and
install either fedora 7 or debian unstabl
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>
>> Except that I wanted to change the hypercall to allow querying of real
>> time or "available" time as VMI puts it.
>>
>
> I see. You could have an interface like Xen's runstate interface, which
> gives you a breakdown of how long eac
It is likely that guest stops to receive interrupt. I met this issue in
debuging
in kernel PIC patch. The normal reason is that a previous irq injection
fails (IDT_Vectoring valid). It seems currnet KVM handling to
IDT_Vectoring
doesn't cover all situation.
(The in Kernel PIC patch will try to co
On Mon, 2007-06-18 at 12:09 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Sun, 2007-06-17 at 17:25 +0300, Avi Kivity wrote:
> >
> >> Rusty Russell wrote:
> >>
> >>> + /* Set up for reply. */
> >>> + vblk->sg[0].page = virt_to_page(&vbr->in_hdr);
> >>> + vblk->sg[0].offset = offset_
Bugs item #1739503, was opened at 2007-06-19 10:27
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=1739503&group_id=180599
Please note that this message will contain a full copy
64 matches
Mail list logo
