You can subscribe to this list here.
2008 |
Jan
(41) |
Feb
(101) |
Mar
(164) |
Apr
(94) |
May
(27) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Yang, S. <she...@in...> - 2008-04-24 12:58:48
|
On Thursday 24 April 2008 20:54:10 Avi Kivity wrote: > I propose moving the kvm lists to vger.kernel.org, for the following > benefits: > > - better spam control > - faster service (I see significant lag with the sourceforge lists) > - no ads appended to the end of each email > > If no objections are raised, and if the vger postmasters agree, I will > mass subscribe the current subscribers so that there will be no service > interruption. > > Opinions? Yeah, finally we don't need to meet something like this everyday: "This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/" ;) -- Thanks Yang, Sheng |
From: Avi K. <av...@qu...> - 2008-04-24 12:54:18
|
I propose moving the kvm lists to vger.kernel.org, for the following benefits: - better spam control - faster service (I see significant lag with the sourceforge lists) - no ads appended to the end of each email If no objections are raised, and if the vger postmasters agree, I will mass subscribe the current subscribers so that there will be no service interruption. Opinions? -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-23 13:59:38
|
The preliminary KVM Forum 2008 agenda is now online at http://kforum.qumranet.com/KVMForum/agenda.php If you haven't done so already, please register! There is a big "Register Now" button on the page. Early bird registration ends May 1. Note we have a few more sessions in the pipeline; the page will be updated in a few days. [Speakers: if we've misspelled your name or if you'd like to change your slot, let us know] -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. |
From: Jes S. <je...@sg...> - 2008-04-23 12:52:35
|
>>>>> "Jes" == Jes Sorensen <je...@sg...> writes: Jes> Hi, Finally got the latest KVM sources to build and boot Jes> here. Now playing with the networking again, but I am getting the Jes> same problem with the e1000 driver that I had with the early Jes> drivers. Jes> Anyone have ideas how to approach this one: Jes> Intel(R) PRO/1000 Network Driver - version 7.2.7-k2-NAPI Jes> Copyright (c) 1999-2006 Intel Corporation. register_intr: No Jes> IOSAPIC for GSI 28 ACPI: PCI Interrupt 0000:00:03.0[A]: failed to Jes> register GSI ..... I should add to this: lspci claims the interrupt is 11, but the IDE driver is able to probe and run with interrupts. In that case lspci claims irq 6 for ide, but /proc/interrupts shows ide configured with interrupts 33+34. Cheers, Jes |
From: Jes S. <je...@sg...> - 2008-04-23 12:24:07
|
Hi, Finally got the latest KVM sources to build and boot here. Now playing with the networking again, but I am getting the same problem with the e1000 driver that I had with the early drivers. Anyone have ideas how to approach this one: Intel(R) PRO/1000 Network Driver - version 7.2.7-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. register_intr: No IOSAPIC for GSI 28 ACPI: PCI Interrupt 0000:00:03.0[A]: failed to register GSI ..... and then no Ethernet device available. Cheers, Jes |
From: Hollis B. <ho...@us...> - 2008-04-22 23:54:20
|
On Tuesday 22 April 2008 17:13:01 Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Tuesday 22 April 2008 16:05:38 Rusty Russell wrote: > > > >> On Wednesday 23 April 2008 06:29:14 Hollis Blanchard wrote: > >> > >>> On Tuesday 22 April 2008 09:31:35 Rusty Russell wrote: > >>> > >>>> We may still regret not doing *everything* little-endian, but this > >>>> doesn't make it worse. > >>>> > >>> Hmm, why *don't* we just do everything LE, including the ring? > >>> > >> Mainly because when requirements are in doubt, simplicity wins, I think. > >> > > > > Well, I think the definition of simplicity is up for debate in this > > case... "LE everywhere" is much simpler than "it depends", IMHO. > > > > You couldn't use the vringfd direct ring mapping optimization in KVM for > PPC without teaching the kernel to access a vring in LE format. I'm > pretty sure the later would get rejected on LKML anyway for vringfd as a > generic mechanism. (Since the IA64 guys have already implemented BE guests on LE hosts, they should be aware of this discussion too, which is why I've CCed them.) After a short but torturous whiteboard session, followed by a much longer but less painful discussion, I'm fine with the virtio device config space being BE for PowerPC and LE for x86. In the future, we can use a feature bit to indicate that PCI config space contains an explicit endianness flag. (This will be set to BE or LE, *not* to "opposite of normal", because "normal" is also too vague.) -- Hollis Blanchard IBM Linux Technology Center |
From: Avi K. <av...@qu...> - 2008-04-22 11:18:16
|
Jes Sorensen wrote: > Hi, > > This one fixes a segfault problem I am seeing on ia64 due to the > malloc'ed address being truncated to 32 bit. > Applied, thanks. -- error compiling committee.c: too many arguments to function |
From: Avi K. <av...@qu...> - 2008-04-22 08:53:13
|
[Note: KVM Forum registration is now open at http://kforum.qumranet.com/KVMForum/about_kvmforum.php] [The deadline for submitting presentations has been extended by two weeks, until May 4th] This is the Call for Presentations for the second annual KVM Developer's Forum, to be held on June 10-13, 2008, in Napa, California, USA [1]. We are looking for presentations on KVM development, quality assurance, management, security, interoperability, architecture support, and interesting use cases. Presentations are 50 minutes in length; there are also 25-minute mini-presentation slots available. KVM Forum presentations are an excellent way to inform the KVM development community about your work, and to gather valuable feedback about your approach. Please send your presentation proposal to the KVM Forum 2008 Content Committee at kf2...@qu... by May 4th. KVM Forum 2008 Content Committee: Dor Laor Anthony Liguori Avi Kivity [1] http://kforum.qumranet.com/KVMForum/about_kvmforum.php -- Any sufficiently difficult bug is indistinguishable from a feature. |
From: Jes S. <je...@sg...> - 2008-04-21 15:35:19
|
Hi, This one fixes a segfault problem I am seeing on ia64 due to the malloc'ed address being truncated to 32 bit. Cheers, Jes |
From: Avi K. <av...@qu...> - 2008-04-17 14:02:17
|
[Note: KVM Forum registration is now open at http://kforum.qumranet.com/KVMForum/about_kvmforum.php] This is the Call for Presentations for the second annual KVM Developer's Forum, to be held on June 10-13, 2008, in Napa, California, USA [1]. We are looking for presentations on KVM development, quality assurance, management, security, interoperability, architecture support, and interesting use cases. Presentations are 50 minutes in length; there are also 25-minute mini-presentation slots available. KVM Forum presentations are an excellent way to inform the KVM development community about your work, and to gather valuable feedback about your approach. Please send your presentation proposal to the KVM Forum 2008 Content Committee at kf2...@qu... by April 20th. KVM Forum 2008 Content Committee: Dor Laor Anthony Liguori Avi Kivity [1] http://kforum.qumranet.com/KVMForum/about_kvmforum.php -- Any sufficiently difficult bug is indistinguishable from a feature. |
From: Avi K. <av...@qu...> - 2008-04-17 08:18:12
|
Marcelo Tosatti wrote: > On Wed, Apr 16, 2008 at 11:21:05AM -0500, Hollis Blanchard wrote: > >> By the way Marcelo, it would be polite to provide these stubs yourself to >> avoid breaking the build on other architectures. >> > > Indeed, should have been more careful. > > And I should have caught this on my build machine. I'll get this automated. >> It looks like IA64 is still broken because of this. >> > > Now I'm not sure if IA64 supports migration. Should it return -EINVAL or > the ia64 mpstate ? > There is an mp_state in ia64's kvm_regs, so this is already taken care of. -- error compiling committee.c: too many arguments to function |
From: Marcelo T. <mto...@re...> - 2008-04-16 17:40:59
|
On Wed, Apr 16, 2008 at 11:21:05AM -0500, Hollis Blanchard wrote: > By the way Marcelo, it would be polite to provide these stubs yourself to > avoid breaking the build on other architectures. Indeed, should have been more careful. > It looks like IA64 is still broken because of this. Now I'm not sure if IA64 supports migration. Should it return -EINVAL or the ia64 mpstate ? |
From: Hollis B. <ho...@us...> - 2008-04-16 16:27:32
|
By the way Marcelo, it would be polite to provide these stubs yourself to avoid breaking the build on other architectures. It looks like IA64 is still broken because of this. -- Hollis Blanchard IBM Linux Technology Center On Wednesday 16 April 2008 09:06:34 Carsten Otte wrote: > From: Christian Borntraeger <bor...@de...> > > Since > > commit ded6fb24fb694bcc5f308a02ec504d45fbc8aaa6 > Author: Marcelo Tosatti <mto...@re...> > Date: Fri Apr 11 13:24:45 2008 -0300 > KVM: add ioctls to save/store mpstate > > kvm does not compile on s390. > This patch provides ioctl stubs for s390 to make kvm.git compile again. > As migration is not yet supported, the ioctl definitions are empty. > > Signed-off-by: Christian Borntraeger <bor...@de...> > Signed-off-by: Carsten Otte <co...@de...> > --- > arch/s390/kvm/kvm-s390.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > Index: kvm/arch/s390/kvm/kvm-s390.c > =================================================================== > --- kvm.orig/arch/s390/kvm/kvm-s390.c > +++ kvm/arch/s390/kvm/kvm-s390.c > @@ -414,6 +414,18 @@ int kvm_arch_vcpu_ioctl_debug_guest(stru > return -EINVAL; /* not implemented yet */ > } > > +int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu, > + struct kvm_mp_state *mp_state) > +{ > + return -EINVAL; /* not implemented yet */ > +} > + > +int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu, > + struct kvm_mp_state *mp_state) > +{ > + return -EINVAL; /* not implemented yet */ > +} > + > static void __vcpu_run(struct kvm_vcpu *vcpu) > { > memcpy(&vcpu->arch.sie_block->gg14, &vcpu->arch.guest_gprs[14], 16); > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel > |
From: Hollis B. <ho...@us...> - 2008-04-15 18:21:41
|
On Tuesday 15 April 2008 11:20:58 Jerone Young wrote: > > What happened to my suggestion of creating a per-arch HACK_FILES and > > UNIFDEF_FILES variables, and looping over those? > > These macros are only for x86. We don't want them or need them. So I > just left them be as not to accidentally miss or break anything. Right, they are only used for x86. So as I said before, create arch-specific HACK_FILES and UNIFDEF_FILES variables, and use those instead. -- Hollis Blanchard IBM Linux Technology Center |
From: Jerone Y. <jy...@us...> - 2008-04-15 16:21:07
|
On Tue, 2008-04-15 at 09:08 -0500, Hollis Blanchard wrote: > On Monday 14 April 2008 21:46:43 Jerone Young wrote: > > 1 file changed, 13 insertions(+), 5 deletions(-) > > kernel/Makefile | 18 +++++++++++++----- > > > > > > This patch add the ability for make sync in the kernel directory to work > > for mulitiple architectures and not just x86. > > > > Signed-off-by: Jerone Young <jy...@us...> > > > > diff --git a/kernel/Makefile b/kernel/Makefile > > --- a/kernel/Makefile > > +++ b/kernel/Makefile > > @@ -1,5 +1,10 @@ include ../config.mak > > include ../config.mak > > > > +ASM_DIR=$(ARCH) > > +ifneq '$(filter $(ASM_DIR), x86_64 i386 ia64)' '' > > + ASM_DIR=x86 > > +endif > > Minor complaint: "ASM_DIR" really isn't. You use it as arch/$(ASM_DIR) and > also as include/asm-$(ASM_DIR). I think what you really meant is "ARCH_DIR" > (or similar). I can change it. Not that big of a deal. Oh left the ia64 on there by accident. > > > +ifneq '$(filter $(ASM_DIR), x86_64 i386 ia64)' '' > > $(call unifdef, include/linux/kvm.h) > > $(call unifdef, include/linux/kvm_para.h) > > $(call unifdef, include/asm-x86/kvm.h) > > @@ -54,6 +60,8 @@ sync: > > $(call hack, svm.c) > > $(call hack, x86.c) > > $(call hack, irq.h) > > +endif > > + > > Why are you keeping IA64 touching asm-x86? Accident. Cut and past error from the first mistake. > > What happened to my suggestion of creating a per-arch HACK_FILES and > UNIFDEF_FILES variables, and looping over those? These macros are only for x86. We don't want them or need them. So I just left them be as not to accidentally miss or break anything. > |
From: Hollis B. <ho...@us...> - 2008-04-15 14:10:47
|
On Monday 14 April 2008 21:46:43 Jerone Young wrote: > 1 file changed, 13 insertions(+), 5 deletions(-) > kernel/Makefile | 18 +++++++++++++----- > > > This patch add the ability for make sync in the kernel directory to work > for mulitiple architectures and not just x86. > > Signed-off-by: Jerone Young <jy...@us...> > > diff --git a/kernel/Makefile b/kernel/Makefile > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -1,5 +1,10 @@ include ../config.mak > include ../config.mak > > +ASM_DIR=$(ARCH) > +ifneq '$(filter $(ASM_DIR), x86_64 i386 ia64)' '' > + ASM_DIR=x86 > +endif Minor complaint: "ASM_DIR" really isn't. You use it as arch/$(ASM_DIR) and also as include/asm-$(ASM_DIR). I think what you really meant is "ARCH_DIR" (or similar). > +ifneq '$(filter $(ASM_DIR), x86_64 i386 ia64)' '' > $(call unifdef, include/linux/kvm.h) > $(call unifdef, include/linux/kvm_para.h) > $(call unifdef, include/asm-x86/kvm.h) > @@ -54,6 +60,8 @@ sync: > $(call hack, svm.c) > $(call hack, x86.c) > $(call hack, irq.h) > +endif > + Why are you keeping IA64 touching asm-x86? What happened to my suggestion of creating a per-arch HACK_FILES and UNIFDEF_FILES variables, and looping over those? -- Hollis Blanchard IBM Linux Technology Center |
From: MR. B. L. <mr....@na...> - 2008-04-15 04:42:12
|
>From Mr. Barry Leonard. PO Box 10720 217 Strand London WC2R 1AP My Request. I Have a very important request that make me to contact you; I am Mr. Barry Leonard, I found Your profile very interesting and decided to reach you directly to solicit your assistance and Guidelines in making a business investment and transfer of £12.500000,000 (Twelve Million Five Hundred thousand pounds Sterling) to your country within the Next few days. I presently work as a senior Accounts Director, Offshore Mortgage & Services with Natwest Bank Plc, London. But at this moment, I am constrained to issue more details about this profitable Business investment until I get your response by mail. This transaction is totally free of risk and troubles as the fund is legitimate and does not originate from drug, money laundry, terrorism or any other illegal act, funds will be released to you after necessary processes have been followed. Please take out a moment of your very busy Schedule today to respond back if you are interested; please send your direct telephone numbers through email for an initial confidential communication. I wish for utmost confidentiality in handling this transaction. Awaiting your reply, Mr. Barry Leonard Snr.Accounts Director |
From: Avi K. <av...@qu...> - 2008-04-08 00:17:58
|
[Note: KVM Forum registration is now open at http://kforum.qumranet.com/KVMForum/about_kvmforum.php] This is the Call for Presentations for the second annual KVM Developer's Forum, to be held on June 10-13, 2008, in Napa, California, USA [1]. We are looking for presentations on KVM development, quality assurance, management, security, interoperability, architecture support, and interesting use cases. Presentations are 50 minutes in length; there are also 25-minute mini-presentation slots available. KVM Forum presentations are an excellent way to inform the KVM development community about your work, and to gather valuable feedback about your approach. Please send your presentation proposal to the KVM Forum 2008 Content Committee at kf2...@qu... by April 20th. KVM Forum 2008 Content Committee: Dor Laor Anthony Liguori Avi Kivity [1] http://kforum.qumranet.com/KVMForum/about_kvmforum.php -- Any sufficiently difficult bug is indistinguishable from a feature. |
From: Rami T. <ra...@qu...> - 2008-04-06 16:42:33
|
The registration site for KVM developer forum 2008 is now open (http://kforum.qumranet.com/KVMForum/register_now.php ) The participation fee is US$ 695 for early bird subscribers up to May 1st, 2008. After May 1st 2008, the participation fee is US$ 790. Developers whose registration fee is not paid by an employer or organization can attend for free. Please contact the event team if you are interested in registering as an "unaffiliated" attendee. To get more details and register please go to: http://kforum.qumranet.com/KVMForum/about_kvmforum.php See you all there. Rami |
From: Avi K. <av...@qu...> - 2008-04-06 09:08:55
|
Zhang, Xiantao wrote: > Compared with V9, just fixed indentation issues in patch 12. I put it > the patchset in > git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git > kvm-ia64-mc10. Please help to review. > Specially, the first two patches (TR Management patch and > smp_call_function_mask patch) needs Tony's review and Ack. Thanks:-) > Rebased and merged the latest version into kvm.git. Thanks. -- error compiling committee.c: too many arguments to function |
From: Zhang, X. <xia...@in...> - 2008-04-03 02:21:11
|
Compared with V9, just fixed indentation issues in patch 12. I put it the patchset in git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git kvm-ia64-mc10. Please help to review. Specially, the first two patches (TR Management patch and smp_call_function_mask patch) needs Tony's review and Ack. Thanks:-) Xiantao |
From: Luck, T. <ton...@in...> - 2008-04-02 23:53:30
|
> > Have you looked at Jens Axboe's patches to make all this stuff a lot > > more arch-common? > > Nope, do you have a pointer? Check your favourite archive for this Subject line: Generic smp_call_function(), improvements, and smp_call_function_single() -Tony |
From: Jes S. <je...@sg...> - 2008-04-02 07:30:56
|
Jeremy Fitzhardinge wrote: >> I wasn't suggesting we shouldn't have both interfaces, merely >> questioning why adding what to me seems like an unnecessary performance >> hit for the classic case of the call. > > I don't mind how many interfaces there are, so long as there only needs > to be one place to hook to plug in the Xen version of > smp_call_function_whatever. Perhaps the answer is to just hook the IPI > mechanism itself rather than the whole of smp_call_function_mask... Well we're obviously going to have at least two interfaces given that we have the traditional Linux one and Xen seems to require something different :-) > Have you looked at Jens Axboe's patches to make all this stuff a lot > more arch-common? Nope, do you have a pointer? Cheers, Jes |
From: Zhang, X. <xia...@in...> - 2008-04-02 03:15:28
|
Changed to be a soft and clear saying. Thanks! :-) Xiantao Jes Sorensen wrote: > Zhang, Xiantao wrote: >>> From 5c70c038c57190144390ae9d30c3d06afba103d4 Mon Sep 17 00:00:00 >>> 2001 >> From: Xiantao Zhang <xia...@in...> >> Date: Tue, 1 Apr 2008 14:59:30 +0800 >> Subject: [PATCH] KVM:IA64 : Add kvm sal/pal virtulization support. >> >> Some sal/pal calls would be traped to kvm for virtulization >> from guest firmware. >> Signed-off-by: Xiantao Zhang <xia...@in...> --- >> arch/ia64/kvm/kvm_fw.c | 500 > > Hi Xiantao, > > A few more comments: > > >> --- /dev/null >> +++ b/arch/ia64/kvm/kvm_fw.c > >> +static void kvm_get_pal_call_data(struct kvm_vcpu *vcpu, >> + u64 *gr28, u64 *gr29, u64 *gr30, u64 *gr31) { >> + struct exit_ctl_data *p; >> + >> + if (vcpu) { >> + p = &vcpu->arch.exit_data; >> + if (p->exit_reason == EXIT_REASON_PAL_CALL) { >> + *gr28 = p->u.pal_data.gr28; >> + *gr29 = p->u.pal_data.gr29; >> + *gr30 = p->u.pal_data.gr30; >> + *gr31 = p->u.pal_data.gr31; >> + return ; >> + } >> + } >> + printk(KERN_DEBUG"Error occurs in kvm_get_pal_call_data!!\n"); > > Maybe make this error message a bit more elaborate with information > about what the error is? > >> +static void set_sal_result(struct kvm_vcpu *vcpu, >> + struct sal_ret_values result) { >> + struct exit_ctl_data *p; >> + >> + p = kvm_get_exit_data(vcpu); >> + if (p && p->exit_reason == EXIT_REASON_SAL_CALL) { >> + p->u.sal_data.ret = result; >> + return ; >> + } >> + printk(KERN_WARNING"Error occurs!!!\n"); > > I love this error message :-) Seriously though, please make it say > where it is and what has been detected. > > Cheers, > Jes > > ------------------------------------------------------------------------ - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp lace > _______________________________________________ > kvm-ia64-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel |
From: Zhang, X. <xia...@in...> - 2008-04-02 02:37:10
|
Fixed. Thanks :) Jes Sorensen wrote: > Zhang, Xiantao wrote: >>> From 0d698efed15759b49e78adcef085feda0a14a175 Mon Sep 17 00:00:00 >>> 2001 >> From: Xiantao Zhang <xia...@in...> >> Date: Tue, 1 Apr 2008 14:57:09 +0800 >> Subject: [PATCH] KVM:IA64: Add optimization for some virtulization >> faults >> >> optvfault.S Add optimization for some performance-critical >> virtualization faults. Signed-off-by: Anthony Xu >> <ant...@in...> >> Signed-off-by: Xiantao Zhang <xia...@in...> --- >> arch/ia64/kvm/optvfault.S | 918 >> +++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 918 insertions(+), 0 deletions(-) >> create mode 100644 arch/ia64/kvm/optvfault.S > > Hi Xiantao, > > This one still suffers from the bad indentation. > > Cheers, > Jes > > ------------------------------------------------------------------------ - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp lace > _______________________________________________ > kvm-devel mailing list > kvm...@li... > https://lists.sourceforge.net/lists/listinfo/kvm-devel |