Re: [kvm-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?
> "Avi" == Avi Kivity <[EMAIL PROTECTED]> writes: Avi> kvm-devel doesn't do manual moderation. If vger has the Avi> infrastructure, I don't see why you can't continue doing this on Avi> kvm-ppc-devel. Please don't do this for the kvm-ia64 list either. Avi> btw, we can probably shorten the names to kvm@ and kvm-$arch@ Avi> while we're at it. Either way works IMHO. Cheers, Jes - 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch] qemu/ia64 include prototype for qemu_mallocz
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
Include qemu-common.h for the prototype for qemu_mallocz to avoid
the being truncated to 32 bit.
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
---
target-ia64/op_helper.c |1 +
1 file changed, 1 insertion(+)
Index: qemu/target-ia64/op_helper.c
===
--- qemu.orig/target-ia64/op_helper.c
+++ qemu/target-ia64/op_helper.c
@@ -25,6 +25,7 @@
#include "exec-all.h"
#include "qemu-kvm.h"
+#include "qemu-common.h"
CPUState *cpu_ia64_init(char *cpu_model){
CPUState *env;
-
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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [02/17][PATCH] Implement smp_call_function_mask for ia64 - V8
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 - 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/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [16/18]KVM:IA64 : Add kvm sal/pal virtulization support.V9
Zhang, Xiantao wrote:
>>From 5c70c038c57190144390ae9d30c3d06afba103d4 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> ---
> 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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [13/18] KVM:IA64: Add optimization for some virtulization faults V9
Zhang, Xiantao wrote: >>From 0d698efed15759b49e78adcef085feda0a14a175 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> > --- > 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/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [07/17][PATCH] kvm/ia64: Add TLB virtulization support.-V8
Zhang, Xiantao wrote:
>>From 6b731c15afa8cec84f16408c421c286f1dd1b7d3 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Wed, 12 Mar 2008 13:45:40 +0800
> Subject: [PATCH] KVM:IA64 : Add TLB virtulization support.
>
> vtlb.c includes tlb/VHPT virtulization.
> Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
> Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
Hi Xiantao,
Just a clarification question on this one:
> +void machine_tlb_purge(u64 va, u64 ps)
> +{
> + ia64_ptcl(va, ps << 2);
> +}
What is the purpose of machine_tlb_purge()? Is it supposed to do a
global purge of the tlb on the host machine? If so, how does this macro
differ from platform_global_tlb_purge()?
I am mentioning this because it's very important to keep in mind that
the regular tlb purging instructions are not functional on all ia64
platforms, which is why we have special implementations via the
machine vector interface.
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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [02/17][PATCH] Implement smp_call_function_mask for ia64 - V8
Jeremy Fitzhardinge wrote: > Jes Sorensen wrote: > This change has been on the x86 side for ages, and not even Ingo made a > peep about it ;) Mmmm, last time I looked, x86 didn't scale to any interesting number of CPUs :-) >> Why not keep smp_call_function() the way it was before, rather than >> implementing it via the call to smp_call_function_mask()? > > Because Xen needs a different core implementation (because of its > different IPI implementation), and it would be better to just have to do > one of them rather than N. 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. 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/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [05/17][PATCH] kvm/ia64 : Add head files for kvm/ia64
Hi Xiantao,
More comments.
Zhang, Xiantao wrote:
>>From 696b9eea9f5001a7b7a07c0e58514aa10306b91a Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Fri, 28 Mar 2008 09:51:36 +0800
> Subject: [PATCH] KVM:IA64 : Add head files for kvm/ia64
>
> ia64_regs: some defintions for special registers
> which aren't defined in asm-ia64/ia64regs.
Please put missing definitions of registers into asm-ia64/ia64regs.h if
they are official definitions from the spec.
> kvm_minstate.h : Marcos about Min save routines.
> lapic.h: apic structure definition.
> vcpu.h : routions related to vcpu virtualization.
> vti.h : Some macros or routines for VT support on Itanium.
> Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
> +/*
> + * Flushrs instruction stream.
> + */
> +#define ia64_flushrs() asm volatile ("flushrs;;":::"memory")
> +
> +#define ia64_loadrs() asm volatile ("loadrs;;":::"memory")
Please put these into include/asm-ia64/gcc_intrin.h
> +#define ia64_get_rsc()
> \
> +({
> \
> + unsigned long val;
> \
> + asm volatile ("mov %0=ar.rsc;;" : "=r"(val) :: "memory");
> \
> + val;
> \
> +})
> +
> +#define ia64_set_rsc(val)\
> + asm volatile ("mov ar.rsc=%0;;" :: "r"(val) : "memory")
Please update the ia64_get/set_reg macros to handle the RSC register
and use those macros.
> +#define ia64_get_bspstore()
> \
> +({
> \
> + unsigned long val;
> \
> + asm volatile ("mov %0=ar.bspstore;;" : "=r"(val) :: "memory");
> \
> + val;
> \
> +})
Ditto for for AR.BSPSTORE
> +#define ia64_get_rnat()
> \
> +({
> \
> + unsigned long val;
> \
> + asm volatile ("mov %0=ar.rnat;" : "=r"(val) :: "memory");
> \
> + val;
> \
> +})
Ditto for AR.RNAT
> +static inline unsigned long ia64_get_itc(void)
> +{
> + unsigned long result;
> + result = ia64_getreg(_IA64_REG_AR_ITC);
> + return result;
> +}
This exists in include/asm-ia64/delay.h
> +static inline void ia64_set_dcr(unsigned long dcr)
> +{
> + ia64_setreg(_IA64_REG_CR_DCR, dcr);
> +}
Please just call ia64_setreg() in your code rather than defining a
wrapper for it.
> +#define ia64_ttag(addr)
> \
> +({
> \
> + __u64 ia64_intri_res;
> \
> + asm volatile ("ttag %0=%1" : "=r"(ia64_intri_res) : "r" (addr));
> \
> + ia64_intri_res;
> \
> +})
Please add to include/asm-ia64/gcc_intrin.h instead.
> diff --git a/arch/ia64/kvm/lapic.h b/arch/ia64/kvm/lapic.h
> new file mode 100644
> index 000..152cbdc
> --- /dev/null
> +++ b/arch/ia64/kvm/lapic.h
> @@ -0,0 +1,27 @@
> +#ifndef __KVM_IA64_LAPIC_H
> +#define __KVM_IA64_LAPIC_H
> +
> +#include "iodev.h"
I don't understand why iodev.h is included here?
> --- /dev/null
> +++ b/arch/ia64/kvm/vcpu.h
The formatting of this file is dodgy, please try and make it comply with
the Linux standards in Documentation/CodingStyle
> +#define _vmm_raw_spin_lock(x)
> \
[snip]
> +
> +#define _vmm_raw_spin_unlock(x) \
Could you explain the reasoning behind these two macros? Whenever I see
open coded spin lock modifications like these, I have to admit I get a
bit worried.
> +typedef struct kvm_vcpu VCPU;
> +typedef struct kvm_pt_regs REGS;
> +typedef enum { DATA_REF, NA_REF, INST_REF, RSE_REF } vhpt_ref_t;
> +typedef enum { INSTRUCTION, DATA, REGISTER } miss_type;
ARGH! Please see previous mail about typedefs! I suspect this is code
inherited from Xen ? Xen has a lot of really nasty and pointless
typedefs like these :-(
> +static inline void vcpu_set_dbr(VCPU *vcpu, u64 reg, u64 val)
> +{
> + /* TODO: need to virtualize */
> + __ia64_set_dbr(reg, val);
> +}
> +
> +static inline void vcpu_set_ibr(VCPU *vcpu, u64 reg, u64 val)
> +{
> + /* TODO: need to virtualize */
> + ia64_set_ibr(reg, val);
> +}
> +
> +static inline u64 vcpu_get_dbr(VCPU *vcpu, u64 reg)
> +{
> + /* TODO: need to virtualize */
> + return ((u64)__ia64_get_dbr(reg));
> +}
> +
> +static inline u64 vcpu_get_ibr(VCPU *vcpu, u64 reg)
> +{
> + /* TODO: need to virtualize */
> + return ((u64)ia64_get_ibr(reg));
> +}
More wrapper macros that really should just use ia64_get/set_reg()
directly in the code.
> diff --git a/arch/ia64/kvm/vti.h b/arch/ia64/kvm/vti.h
> new file mode 100644
> index 000..591ab22
[ship]
> +/* -*- Mode:C; c-basic-offset:4; tab-width:4; indent-tabs-mode:nil -*-
> */
Evil formatting again!
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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [04/17] [PATCH] Add kvm arch-specific core code for kvm/ia64.-V8
Zhang, Xiantao wrote:
>>From 62895ff991d48398a77afdbf7f2bef127e802230 Mon Sep 17 00:00:00 2001
> From: Xiantao Zhang <[EMAIL PROTECTED]>
> Date: Fri, 28 Mar 2008 09:49:57 +0800
> Subject: [PATCH] KVM: IA64: Add kvm arch-specific core code for
> kvm/ia64.
>
> kvm_ia64.c is created to handle kvm ia64-specific core logic.
> Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
More comments, a couple of bugs in this one.
> +#include
> +#include
Don't think you need vmalloc.h here.
> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs
> *regs)
> +{
[snip]
> + copy_from_user(&vcpu->arch.guest, regs->saved_guest,
> + sizeof(union context));
> + copy_from_user(vcpu + 1, regs->saved_stack + sizeof(struct
> kvm_vcpu),
> + IA64_STK_OFFSET - sizeof(struct kvm_vcpu));
You need to check the return values from copy_from_user() here and
deal with possible failure.
> + vcpu->arch.apic = kzalloc(sizeof(struct kvm_lapic), GFP_KERNEL);
> + vcpu->arch.apic->vcpu = vcpu;
Whoops! Missing NULL pointer check here after the kzalloc.
> + copy_to_user(regs->saved_guest, &vcpu->arch.guest,
> + sizeof(union context));
> + copy_to_user(regs->saved_stack, (void *)vcpu, IA64_STK_OFFSET);
Same problem as above - check the return values.
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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [03/15][PATCH] kvm/ia64: Add header files for kvm/ia64. V8
Hi Xiantao,
Some more nit-picking, though some of this is a bit more important
to fixup.
Cheers,
Jes
> +typedef struct thash_data {
Urgh! argh! Please avoid typedefs unless you really need them, see
Chapter 5 of Documentation/CodingStyle for details.
> diff --git a/include/asm-ia64/kvm_host.h b/include/asm-ia64/kvm_host.h
> new file mode 100644
> index 000..522bde0
> --- /dev/null
> +++ b/include/asm-ia64/kvm_host.h
> @@ -0,0 +1,530 @@
> +/* -*- Mode:C; c-basic-offset:4; tab-width:4; indent-tabs-mode:nil -*-
> */
The standard indentation for Linux is 8 characters using tabs. If
possible it's preferred to comply with that to make the entire kernel
tree easier for everybody to deal with. See CodingStyle for details.
> +struct kvm_mmio_req {
> + uint64_t addr; /* physical address*/
> + uint64_t size; /* size in bytes */
> + uint64_t data; /* data (or paddr of data) */
> + uint8_t state:4;
> + uint8_t dir:1; /* 1=read, 0=write */
> +};
> +typedef struct kvm_mmio_req mmio_req_t;
More typedefs
> +/*Pal data struct */
> +typedef struct pal_call{
and again.
> + /*In area*/
> + uint64_t gr28;
> + uint64_t gr29;
> + uint64_t gr30;
> + uint64_t gr31;
> + /*Out area*/
> + struct ia64_pal_retval ret;
> +} pal_call_t;
> +
> +/* Sal data structure */
> +typedef struct sal_call{
and again...
> + /*In area*/
> + uint64_t in0;
> + uint64_t in1;
> + uint64_t in2;
> + uint64_t in3;
> + uint64_t in4;
> + uint64_t in5;
> + uint64_t in6;
> + uint64_t in7;
> + /*Our area*/
> + struct sal_ret_values ret;
> +} sal_call_t;
-
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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [02/17][PATCH] Implement smp_call_function_mask for ia64 - V8
Zhang, Xiantao wrote: >>From 697d50286088e98da5ac8653c80aaa96c81abf87 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <[EMAIL PROTECTED]> > Date: Mon, 31 Mar 2008 09:50:24 +0800 > Subject: [PATCH] KVM:IA64: Implement smp_call_function_mask for ia64 > > This function provides more flexible interface for smp > infrastructure. > Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> Hi Xiantao, I'm a little wary of the performance impact of this change. Doing a cpumask compare on all smp_call_function calls seems a little expensive. Maybe it's just noise in the big picture compared to the actual cost of the IPIs, but I thought I'd bring it up. Keep in mind that a cpumask can be fairly big these days, max NR_CPUS is currently 4096. For those booting a kernel with NR_CPUS at 4096 on a dual CPU machine, it would be a bit expensive. Why not keep smp_call_function() the way it was before, rather than implementing it via the call to smp_call_function_mask()? 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/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [01/17]PATCH Add API for allocating dynamic TR resouce. V8
Hi Xiantao,
I general I think the code in this patch is fine. I have a couple of
nit-picking comments:
> + if (target_mask&0x1) {
The formatting here isn't quite what most of the kernel does. It would
be better if you added spaces so it's a little easier to read, ie:
if (target_mask & 0x1) {
> + p = &__per_cpu_idtrs[cpu][0][0];
> + for (i = IA64_TR_ALLOC_BASE; i <= per_cpu(ia64_tr_used,
> cpu);
> + i++,
> p++) {
> + if (p->pte&0x1)
Same thing here.
> +#define RR_TO_RID(rr) ((rr)<<32>>40)
I would prefer to have this one defined like this:
#define RR_TO_RID(rr) (rr >> 8) & 0xff
It should generate the same code, but is more intuitive for the reader.
Otherwise I think this patch is fine - this is really just cosmetics.
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/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] ia64 kernel patches?
Zhang, Xiantao wrote: > Jes Sorensen wrote: >> Hi Xiantao, >> >> If you could put up the patches somewhere, I could >> help you clean them up and push them. I would prefer not >> to wait until they appear in Linus' tree if possible. > > Hi, Jes > You don't need to wait so long. We will push it to Avi's tree first in > near future once ia64 kernel ready. > Thanks > Xiantao Hi Xiantao, Please, put it in a public tree somewhere, either on kernel.org or a different public server. This is how everybody else does Open Source development - it is much easier in the long run as others will be able to send you fixes instead of waiting 4 months. Thanks, Jes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] ia64 kernel patches?
Zhang, Xiantao wrote: > Hi, Jes > Yes, Anthony and I are working with kernel-ia64 and kvm community to push the > patches. Since kernel should export some interface for kvm use, we have to > wait the response from kernel-ia64. But anyway, It should be picked up in > near future. :) Compared with last push, we added smp guest support and got > more stable status now . > Thanks > Xiantao Hi Xiantao, If you could put up the patches somewhere, I could help you clean them up and push them. I would prefer not to wait until they appear in Linus' tree if possible. Cheers, Jes > > -Original Message- > From: Chris Wright [mailto:[EMAIL PROTECTED] > Sent: 2008年1月25日 2:53 > To: Jes Sorensen > Cc: Zhang, Xiantao; kvm-devel@lists.sourceforge.net > Subject: Re: [kvm-devel] ia64 kernel patches? > > * Jes Sorensen ([EMAIL PROTECTED]) wrote: >> Trying to browse the list archives, but both gmane and sourcefrog's >> interfaces are really painful to deal with. >> >> So, any chance someone could point me at the current ia64 KVM kernel >> patches? I notice they are not yet in Avi's tree. > > The last full round of patches I recall are from December. > Maybe better to get updated patches from Xiantao? > > thanks, > -chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] ia64 kernel patches?
Hi, Trying to browse the list archives, but both gmane and sourcefrog's interfaces are really painful to deal with. So, any chance someone could point me at the current ia64 KVM kernel patches? I notice they are not yet in Avi's tree. Cheers, Jes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
