Re: [RFC PATCH 1/2] Hyper-H reference counter
On Tue, 2013-05-14 at 16:14 +0200, Peter Lieven wrote:
On 13.05.2013 13:45, Vadim Rozenfeld wrote:
Signed-off: Peter Lieven p...@dlh.net
Signed-off: Gleb Natapov g...@redhat.com
Signed-off: Vadim Rozenfeld vroze...@redhat.com
The following patch allows to activate Hyper-V
reference time counter
---
arch/x86/include/asm/kvm_host.h| 2 ++
arch/x86/include/uapi/asm/hyperv.h | 3 +++
arch/x86/kvm/x86.c | 25 -
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h
index 3741c65..f0fee35 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -575,6 +575,8 @@ struct kvm_arch {
/* fields used by HYPER-V emulation */
u64 hv_guest_os_id;
u64 hv_hypercall;
+ u64 hv_ref_count;
+ u64 hv_tsc_page;
#ifdef CONFIG_KVM_MMU_AUDIT
int audit_point;
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm/hyperv.h
index b80420b..9711819 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -136,6 +136,9 @@
/* MSR used to read the per-partition time reference counter */
#define HV_X64_MSR_TIME_REF_COUNT 0x4020
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC 0x4021
+
/* Define the virtual APIC registers */
#define HV_X64_MSR_EOI0x4070
#define HV_X64_MSR_ICR0x4071
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..1a4036d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -843,7 +843,7 @@ EXPORT_SYMBOL_GPL(kvm_rdpmc);
static u32 msrs_to_save[] = {
MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
- HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
+ HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,HV_X64_MSR_TIME_REF_COUNT,
HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN, MSR_KVM_STEAL_TIME,
MSR_KVM_PV_EOI_EN,
MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
@@ -1764,6 +1764,8 @@ static bool kvm_hv_msr_partition_wide(u32 msr)
switch (msr) {
case HV_X64_MSR_GUEST_OS_ID:
case HV_X64_MSR_HYPERCALL:
+ case HV_X64_MSR_REFERENCE_TSC:
+ case HV_X64_MSR_TIME_REF_COUNT:
r = true;
break;
}
@@ -1803,6 +1805,21 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu,
u32 msr, u64 data)
if (__copy_to_user((void __user *)addr, instructions, 4))
return 1;
kvm-arch.hv_hypercall = data;
+ kvm-arch.hv_ref_count = get_kernel_ns();
+ break;
+ }
+ case HV_X64_MSR_REFERENCE_TSC: {
+ u64 gfn;
+ unsigned long addr;
+ u32 tsc_ref;
+ gfn = data HV_X64_MSR_HYPERCALL_PAGE_ADDRESS_SHIFT;
+ addr = gfn_to_hva(kvm, gfn);
+ if (kvm_is_error_hva(addr))
+ return 1;
+ tsc_ref = 0;
+ if(__copy_to_user((void __user *)addr, tsc_ref,
sizeof(tsc_ref)))
+ return 1;
+ kvm-arch.hv_tsc_page = data;
break;
}
default:
@@ -2229,6 +2246,12 @@ static int get_msr_hyperv_pw(struct kvm_vcpu *vcpu,
u32 msr, u64 *pdata)
case HV_X64_MSR_HYPERCALL:
data = kvm-arch.hv_hypercall;
break;
+ case HV_X64_MSR_TIME_REF_COUNT:
+ data = div_u64(get_kernel_ns() - kvm-arch.hv_ref_count,100);
+ break;
in an earlier version of this patch I have the following:
+ case HV_X64_MSR_TIME_REF_COUNT: {
+ u64 now_ns;
+ local_irq_disable();
+ now_ns = get_kernel_ns();
+ data = div_u64(now_ns + kvm-arch.kvmclock_offset -
kvm-arch.hv_ref_count,100);
+ local_irq_enable();
+ break;
+ }
I do not know if this is right, but I can report that this one is working
without any flaws
since approx. 1.5 years.
Hi Peter,
I created this patch based on the original code posted
in thread http://marc.info/?l=kvmm=133278705514826
But please feel free to send your version, if you see any problem
in the current code.
Best regards,
Vadim.
Peter
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Xen as L1 support
Il 15/05/2013 03:24, Ren, Yongjie ha scritto:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
On Behalf Of Alex Palesandro
Sent: Tuesday, May 14, 2013 10:51 PM
To: kvm@vger.kernel.org
Subject: Fwd: Xen as L1 support
Hi,
I'm new to KVM. I'm doing some test on nested Virtualization with Xen
and KVM. I tried to test the Xen hypervisor as L1 over KVM ( Linux
3.9.0) and I found this in
xm dmesg log ( for the complete log, see the attached file).
(XEN) VMX: CPU0 has insufficent VMExit Control (00036fff but requires
min 8200)
(XEN) VMX: failed to initialise.
This is the Acknowledge interrupt on exit control. It shouldn't be
hard to implement it.
Paolo
I found some bug-traces [1] [2] but the hex value here is different from the
previously reported one, so maybe that is a different issue.
Will Xen be supported as L1?
So far, I think it's NO. VMX doesn't work, but PV guest can work in L1 Xen.
There's a bug tracking 'Xen on KVM' issue.
https://bugzilla.kernel.org/show_bug.cgi?id=45931
Best Regards,
Yongjie (Jay)
Many Thanks.
Alex
[1] https://patchwork.kernel.org/patch/1318301/
[2} https://patchwork.kernel.org/patch/789632/
N�r��y���b�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?�)ߢfl===
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock()
On May 14, 2013, at 2:27 AM, Gleb Natapov wrote: +EXPORT_SYMBOL(min_low_pfn); /* defined by bootmem.c, but not exported by generic code */ + What you need this for? It is not used anywhere in this patch and by mips/kvm code in general. I did some digging around myself, since the linker keeps complaining that it can't find min_low_pfn when compiling the KVM module. It seems that it is indirectly pulled in by the cache management functions. Regards Sanjay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock()
On 05/15/2013 08:54 AM, Sanjay Lal wrote: On May 14, 2013, at 2:27 AM, Gleb Natapov wrote: +EXPORT_SYMBOL(min_low_pfn); /* defined by bootmem.c, but not exported by generic code */ + What you need this for? It is not used anywhere in this patch and by mips/kvm code in general. I did some digging around myself, since the linker keeps complaining that it can't find min_low_pfn when compiling the KVM module. It seems that it is indirectly pulled in by the cache management functions. If it is really needed, then the export should probably be done at the site of the min_low_pfn definition, not in some random architecture file. An alternative is to fix the cache management functions so they don't require the export. David Daney Regards Sanjay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: take over co-maintainership from Marcelo, fix MAINTAINERS entry
As announced last week by Marcelo Tosatti, I will be co-maintaining KVM together with Gleb. Cc: Marcelo Tosatti mtosa...@redhat.com Cc: Gleb Natapov g...@redhat.com Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- MAINTAINERS | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7782b..340cb64 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4641,12 +4641,13 @@ F: include/linux/sunrpc/ F: include/uapi/linux/sunrpc/ KERNEL VIRTUAL MACHINE (KVM) -M: Marcelo Tosatti mtosa...@redhat.com M: Gleb Natapov g...@redhat.com +M: Paolo Bonzini pbonz...@redhat.com L: kvm@vger.kernel.org -W: http://kvm.qumranet.com +W: http://linux-kvm.org S: Supported -F: Documentation/*/kvm.txt +F: Documentation/*/kvm*.txt +F: Documentation/virtual/kvm/ F: arch/*/kvm/ F: arch/*/include/asm/kvm* F: include/linux/kvm* -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock()
On Wed, May 15, 2013 at 09:54:24AM -0700, David Daney wrote: On 05/15/2013 08:54 AM, Sanjay Lal wrote: On May 14, 2013, at 2:27 AM, Gleb Natapov wrote: +EXPORT_SYMBOL(min_low_pfn); /* defined by bootmem.c, but not exported by generic code */ + What you need this for? It is not used anywhere in this patch and by mips/kvm code in general. I did some digging around myself, since the linker keeps complaining that it can't find min_low_pfn when compiling the KVM module. It seems that it is indirectly pulled in by the cache management functions. If it is really needed, then the export should probably be done at the site of the min_low_pfn definition, not in some random architecture file. Definitely. We cannot snick it here like that. Please drop it from this patch. An alternative is to fix the cache management functions so they don't require the export. David Daney Regards Sanjay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: limit difference between kvmclock updates
On Tue, May 14, 2013 at 10:12:57AM -0300, Marcelo Tosatti wrote: On Tue, May 14, 2013 at 12:05:13PM +0300, Gleb Natapov wrote: On Thu, May 09, 2013 at 08:21:41PM -0300, Marcelo Tosatti wrote: kvmclock updates which are isolated to a given vcpu, such as vcpu-cpu migration, should not allow system_timestamp from the rest of the vcpus to remain static. Otherwise ntp frequency correction applies to one vcpu's system_timestamp but not the others. So in those cases, request a kvmclock update for all vcpus. The worst case for a remote vcpu to update its kvmclock is then bounded by maximum nohz sleep latency. Does this mean that when one vcpu is migrated all others are kicked out from a guest mode? Yes, those which are in guest mode. For guests with large number of vcpus this is a problem, but i can't see a simpler method to fix the bug for now. Yes, this aspect must be improved (however, the bug incurs on timers in the guest taking tens of milliseconds with vcpu-pcpu pinning, which can be unacceptable). Not sure I understand. With vcpu-pcpu pinning there will be no migration. Do you mean without here? If vcpu-kvm-arch.use_master_clock is false we kick vcpus on each vcpu_load. When is it false? I applied the patch since it fixes the real problem, but we need to evaluate how it affects scalability. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Xen as L1 support
On 2013-05-15 16:59, Paolo Bonzini wrote: Il 15/05/2013 03:24, Ren, Yongjie ha scritto: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Alex Palesandro Sent: Tuesday, May 14, 2013 10:51 PM To: kvm@vger.kernel.org Subject: Fwd: Xen as L1 support Hi, I'm new to KVM. I'm doing some test on nested Virtualization with Xen and KVM. I tried to test the Xen hypervisor as L1 over KVM ( Linux 3.9.0) and I found this in xm dmesg log ( for the complete log, see the attached file). (XEN) VMX: CPU0 has insufficent VMExit Control (00036fff but requires min 8200) (XEN) VMX: failed to initialise. This is the Acknowledge interrupt on exit control. It shouldn't be hard to implement it. Isn't this a pretty recent feature Xen should be able to live without - if it finds itself on a (virtually) older CPU? Jan signature.asc Description: OpenPGP digital signature
Re: Xen as L1 support
On Wed, May 15, 2013 at 04:59:24PM +0200, Paolo Bonzini wrote:
Il 15/05/2013 03:24, Ren, Yongjie ha scritto:
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
On Behalf Of Alex Palesandro
Sent: Tuesday, May 14, 2013 10:51 PM
To: kvm@vger.kernel.org
Subject: Fwd: Xen as L1 support
Hi,
I'm new to KVM. I'm doing some test on nested Virtualization with Xen
and KVM. I tried to test the Xen hypervisor as L1 over KVM ( Linux
3.9.0) and I found this in
xm dmesg log ( for the complete log, see the attached file).
(XEN) VMX: CPU0 has insufficent VMExit Control (00036fff but requires
min 8200)
(XEN) VMX: failed to initialise.
This is the Acknowledge interrupt on exit control. It shouldn't be
hard to implement it.
To run 3.10 as L1 we need it anyway.
Paolo
I found some bug-traces [1] [2] but the hex value here is different from
the
previously reported one, so maybe that is a different issue.
Will Xen be supported as L1?
So far, I think it's NO. VMX doesn't work, but PV guest can work in L1 Xen.
There's a bug tracking 'Xen on KVM' issue.
https://bugzilla.kernel.org/show_bug.cgi?id=45931
Best Regards,
Yongjie (Jay)
Many Thanks.
Alex
[1] https://patchwork.kernel.org/patch/1318301/
[2} https://patchwork.kernel.org/patch/789632/
N�r��y���b�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?�)ߢfl===
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Xen as L1 support
On Wed, May 15, 2013 at 07:43:25PM +0200, Jan Kiszka wrote: On 2013-05-15 16:59, Paolo Bonzini wrote: Il 15/05/2013 03:24, Ren, Yongjie ha scritto: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Alex Palesandro Sent: Tuesday, May 14, 2013 10:51 PM To: kvm@vger.kernel.org Subject: Fwd: Xen as L1 support Hi, I'm new to KVM. I'm doing some test on nested Virtualization with Xen and KVM. I tried to test the Xen hypervisor as L1 over KVM ( Linux 3.9.0) and I found this in xm dmesg log ( for the complete log, see the attached file). (XEN) VMX: CPU0 has insufficent VMExit Control (00036fff but requires min 8200) (XEN) VMX: failed to initialise. This is the Acknowledge interrupt on exit control. It shouldn't be hard to implement it. Isn't this a pretty recent feature Xen should be able to live without - if it finds itself on a (virtually) older CPU? IIRC the feature was always there. KVM started to use it only from 3.10 since posted interrupt requires it. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Xen as L1 support
On 2013-05-15 19:45, Gleb Natapov wrote: On Wed, May 15, 2013 at 07:43:25PM +0200, Jan Kiszka wrote: On 2013-05-15 16:59, Paolo Bonzini wrote: Il 15/05/2013 03:24, Ren, Yongjie ha scritto: -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Alex Palesandro Sent: Tuesday, May 14, 2013 10:51 PM To: kvm@vger.kernel.org Subject: Fwd: Xen as L1 support Hi, I'm new to KVM. I'm doing some test on nested Virtualization with Xen and KVM. I tried to test the Xen hypervisor as L1 over KVM ( Linux 3.9.0) and I found this in xm dmesg log ( for the complete log, see the attached file). (XEN) VMX: CPU0 has insufficent VMExit Control (00036fff but requires min 8200) (XEN) VMX: failed to initialise. This is the Acknowledge interrupt on exit control. It shouldn't be hard to implement it. Isn't this a pretty recent feature Xen should be able to live without - if it finds itself on a (virtually) older CPU? IIRC the feature was always there. KVM started to use it only from 3.10 since posted interrupt requires it. Ah, indeed. Can even find it on a 6-years old Xeon. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock()
On May 15, 2013, at 10:30 AM, Gleb Natapov wrote: On Wed, May 15, 2013 at 09:54:24AM -0700, David Daney wrote: On 05/15/2013 08:54 AM, Sanjay Lal wrote: On May 14, 2013, at 2:27 AM, Gleb Natapov wrote: +EXPORT_SYMBOL(min_low_pfn); /* defined by bootmem.c, but not exported by generic code */ + What you need this for? It is not used anywhere in this patch and by mips/kvm code in general. I did some digging around myself, since the linker keeps complaining that it can't find min_low_pfn when compiling the KVM module. It seems that it is indirectly pulled in by the cache management functions. If it is really needed, then the export should probably be done at the site of the min_low_pfn definition, not in some random architecture file. Definitely. We cannot snick it here like that. Please drop it from this patch. I did export min_low_pfn where it was defined (in .../mm/bootmem.c) as part of the original patch set. It conflicted with the ia64/metag ports. min_low_pfn is exported in arch/ia64/kernel/ia64_ksyms.c and in arch/metag/kernel/metag_ksyms.c. There was some chatter about this when the KVM/MIPS code ended up in linux-next. From what I can gather, the maintainers for the other architectures agreed that exporting this symbol in bootmem.c was fine and should flow from the MIPS tree. I'll do that as part of v2 of the patch set. Regards Sanjay -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM: x86: limit difference between kvmclock updates
On Wed, May 15, 2013 at 08:41:54PM +0300, Gleb Natapov wrote: On Tue, May 14, 2013 at 10:12:57AM -0300, Marcelo Tosatti wrote: On Tue, May 14, 2013 at 12:05:13PM +0300, Gleb Natapov wrote: On Thu, May 09, 2013 at 08:21:41PM -0300, Marcelo Tosatti wrote: kvmclock updates which are isolated to a given vcpu, such as vcpu-cpu migration, should not allow system_timestamp from the rest of the vcpus to remain static. Otherwise ntp frequency correction applies to one vcpu's system_timestamp but not the others. So in those cases, request a kvmclock update for all vcpus. The worst case for a remote vcpu to update its kvmclock is then bounded by maximum nohz sleep latency. Does this mean that when one vcpu is migrated all others are kicked out from a guest mode? Yes, those which are in guest mode. For guests with large number of vcpus this is a problem, but i can't see a simpler method to fix the bug for now. Yes, this aspect must be improved (however, the bug incurs on timers in the guest taking tens of milliseconds with vcpu-pcpu pinning, which can be unacceptable). Not sure I understand. With vcpu-pcpu pinning there will be no migration. Do you mean without here? With vcpu-pcpu pinning there is no guarantee of kvm_arch_vcpu_load therefore no KVM_REQ_UPDATE_CLOCK. This is the problem. If vcpu-kvm-arch.use_master_clock is false we kick vcpus on each vcpu_load. When is it false? When - the host does not use TSC clocksource or - the vcpus TSCs are out of sync I applied the patch since it fixes the real problem, but we need to evaluate how it affects scalability. I'll look into ways to reduce the IPIs. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Qemu-devel] Para-Virtualized Clock Usage
Hi Gleb, On a related note, does Qemu have an option to emulate RDTSC? Thanks, Joji. -Original Message- From: Gleb Natapov [mailto:g...@redhat.com] Sent: Wednesday, April 24, 2013 11:57 PM To: Joji Mekkattuparamban (joji) Cc: Marcelo Tosatti; qemu-de...@nongnu.org; kvm@vger.kernel.org Subject: Re: [Qemu-devel] Para-Virtualized Clock Usage On Thu, Apr 25, 2013 at 12:28:35AM +, Joji Mekkattuparamban (joji) wrote: Thank you Gleb and Marcelo. I will migrate the API using gettimeofday. Is there any dependency on the QEMU or the Guest? If the host supports pvclock and the guest invokes gettimeofday, would the pvclock be automatically used? Or do I require a patch in either the Qemu or the guest kernel? Guest and host kernel should be at least 3.8. IIRC there is not QEMU version dependency. Thanks! Joji. -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Sent: Wednesday, April 24, 2013 1:28 AM To: Gleb Natapov Cc: Joji Mekkattuparamban (joji); qemu-de...@nongnu.org; kvm@vger.kernel.org Subject: Re: [Qemu-devel] Para-Virtualized Clock Usage On Tue, Apr 23, 2013 at 08:52:16AM +0300, Gleb Natapov wrote: On Mon, Apr 22, 2013 at 04:58:01PM +, Joji Mekkattuparamban (joji) wrote: Greetings, I have a SMP guest application, running on the 2.6.27 Linux kernel. The application, originally written for bare metal, makes extensive use of the TSC, by directly invoking rdtsc from the user space for timestamp purposes. While running on KVM (RHEL version 6.3), we are running into TSC issues on some hardware. As a solution, I am considering migrating to the pvclock. I am wondering if there is an example for migrating from TSC to the pvclock. Any pointers? Wrong list, you should ask KVM (copied). Recent kernels have pvclock vdso support which means that gettimeofday() uses it without entering the kernel. Marcelo? -- Gleb. Converting application to make use of gettimeofday() should be the best way to make use of pvclock, yes. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Wed, 2013-05-15 at 14:47 +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
scsi.c includes vhost.c which uses memcpy_fromiovec.
This patch fixes this build failure.
From Randy Dunlap:
'''
on x86_64:
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
It needs to depend on NET since net/core/ provides that function.
'''
Proper fix please.
Though I can't see why you thought this was a good idea. Nonetheless, I
shan't highlight why: I have far too much respect for your intellects
and abilities.
No, don't thank me!
Hi Rusty Asias,
I assume you mean something like the following patch to allow kbuild to
work when VHOST_NET + VHOST_SCSI are both enabled and sharing vhost.o,
yes..?
Also included is dropping the now unnecessary vhost.c include, and
allowing vhost_work_flush() to be accessed externally as scsi.c
currently requires.
MST, care to pick this up..?
--nab
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 8b9226d..016387f 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -1,3 +1,6 @@
+config VHOST
+ tristate
+
config VHOST_NET
tristate Host kernel accelerator for virtio net
depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP)
@@ -12,7 +15,7 @@ config VHOST_NET
config VHOST_SCSI
tristate VHOST_SCSI TCM fabric driver
- depends on TARGET_CORE EVENTFD m
+ depends on NET EVENTFD TARGET_CORE
select VHOST_RING
default n
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 654e9afb..e5b5f0b 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -1,7 +1,9 @@
+obj-$(CONFIG_VHOST) += vhost.o
+
obj-$(CONFIG_VHOST_NET) += vhost_net.o
-vhost_net-y := vhost.o net.o
+vhost_net-objs := net.o
obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
-vhost_scsi-y := scsi.o
+vhost_scsi-objs := scsi.o
obj-$(CONFIG_VHOST_RING) += vringh.o
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 7014202..b5836a2 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -49,7 +49,6 @@
#include linux/llist.h
#include linux/bitmap.h
-#include vhost.c
#include vhost.h
#define TCM_VHOST_VERSION v0.1
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index beee7f5..8cd1562 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -123,7 +123,7 @@ static bool vhost_work_seq_done(struct vhost_dev *dev,
struct vhost_work *work,
return left = 0;
}
-static void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work)
+void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work)
{
unsigned seq;
int flushing;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index a7ad635..50ee396 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -44,6 +44,7 @@ void vhost_poll_init(struct vhost_poll *poll, vhost_work_fn_t
fn,
unsigned long mask, struct vhost_dev *dev);
int vhost_poll_start(struct vhost_poll *poll, struct file *file);
void vhost_poll_stop(struct vhost_poll *poll);
+void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work);
void vhost_poll_flush(struct vhost_poll *poll);
void vhost_poll_queue(struct vhost_poll *poll);
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: allow host header to be included even for !CONFIG_KVM
On Mon, Mar 25, 2013 at 02:14:20PM -0700, Kevin Hilman wrote: Gleb Natapov g...@redhat.com writes: On Sun, Mar 24, 2013 at 02:44:26PM +0100, Frederic Weisbecker wrote: 2013/3/21 Gleb Natapov g...@redhat.com: Isn't is simpler for kernel/context_tracking.c to define empty __guest_enter()/__guest_exit() if !CONFIG_KVM. That doesn't look right. Off-cases are usually handled from the headers, right? So that we avoid iffdeffery ugliness in core code. Lets put it in linux/context_tracking.h header then. Here's a version to do that. Kevin From d9d909394479dd7ff90b7bddb95a564945406719 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@linaro.org Date: Mon, 25 Mar 2013 14:12:41 -0700 Subject: [PATCH v2] ontext_tracking: fix !CONFIG_KVM compile: add stub guest enter/exit Sorry for my very delayed response... When KVM is not enabled, or not available on a platform, the KVM headers should not be included. Instead, just define stub __guest_[enter|exit] functions. May be it would be cleaner to move guest_enter/exit definitions altogether in linux/context_tracking.h After all that's where the implementation mostly belong to. Let me see if I can get that in shape. Thanks. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
Nicholas A. Bellinger n...@linux-iscsi.org writes: On Wed, 2013-05-15 at 14:47 +0930, Rusty Russell wrote: Asias He as...@redhat.com writes: scsi.c includes vhost.c which uses memcpy_fromiovec. This patch fixes this build failure. From Randy Dunlap: ''' on x86_64: ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined! It needs to depend on NET since net/core/ provides that function. ''' Proper fix please. Though I can't see why you thought this was a good idea. Nonetheless, I shan't highlight why: I have far too much respect for your intellects and abilities. No, don't thank me! Hi Rusty Asias, I assume you mean something like the following patch to allow kbuild to work when VHOST_NET + VHOST_SCSI are both enabled and sharing vhost.o, yes..? No, that's a separate issue. memcpy_fromiovec() has nothing to do with networking: that was just the first user. Note that crypto/algif_skcipher.c also uses it. The obvious answer is to move it into lib/. OTOH making vhost_scsi depend on CONFIG_NET is breathtakingly lazy. I expect better from experienced kernel hackers :( Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Wed, May 15, 2013 at 03:37:30PM -0700, Nicholas A. Bellinger wrote:
On Wed, 2013-05-15 at 14:47 +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
scsi.c includes vhost.c which uses memcpy_fromiovec.
This patch fixes this build failure.
From Randy Dunlap:
'''
on x86_64:
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
It needs to depend on NET since net/core/ provides that function.
'''
Proper fix please.
Though I can't see why you thought this was a good idea. Nonetheless, I
shan't highlight why: I have far too much respect for your intellects
and abilities.
No, don't thank me!
Hi Rusty Asias,
I assume you mean something like the following patch to allow kbuild to
work when VHOST_NET + VHOST_SCSI are both enabled and sharing vhost.o,
yes..?
Also included is dropping the now unnecessary vhost.c include, and
allowing vhost_work_flush() to be accessed externally as scsi.c
currently requires.
MST, care to pick this up..?
--nab
Couple of days ago, I have separated the vhost.ko.
'vhost: Make vhost a separate module'
http://www.spinics.net/lists/kvm/msg90825.html
MST wanted to queue it up for 3.11.
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 8b9226d..016387f 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -1,3 +1,6 @@
+config VHOST
+ tristate
+
config VHOST_NET
tristate Host kernel accelerator for virtio net
depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP)
@@ -12,7 +15,7 @@ config VHOST_NET
config VHOST_SCSI
tristate VHOST_SCSI TCM fabric driver
- depends on TARGET_CORE EVENTFD m
+ depends on NET EVENTFD TARGET_CORE
select VHOST_RING
default n
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 654e9afb..e5b5f0b 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -1,7 +1,9 @@
+obj-$(CONFIG_VHOST) += vhost.o
+
obj-$(CONFIG_VHOST_NET) += vhost_net.o
-vhost_net-y := vhost.o net.o
+vhost_net-objs := net.o
obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
-vhost_scsi-y := scsi.o
+vhost_scsi-objs := scsi.o
obj-$(CONFIG_VHOST_RING) += vringh.o
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 7014202..b5836a2 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -49,7 +49,6 @@
#include linux/llist.h
#include linux/bitmap.h
-#include vhost.c
#include vhost.h
#define TCM_VHOST_VERSION v0.1
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index beee7f5..8cd1562 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -123,7 +123,7 @@ static bool vhost_work_seq_done(struct vhost_dev *dev,
struct vhost_work *work,
return left = 0;
}
-static void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work)
+void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work)
{
unsigned seq;
int flushing;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index a7ad635..50ee396 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -44,6 +44,7 @@ void vhost_poll_init(struct vhost_poll *poll,
vhost_work_fn_t fn,
unsigned long mask, struct vhost_dev *dev);
int vhost_poll_start(struct vhost_poll *poll, struct file *file);
void vhost_poll_stop(struct vhost_poll *poll);
+void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work);
void vhost_poll_flush(struct vhost_poll *poll);
void vhost_poll_queue(struct vhost_poll *poll);
--
Asias
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote: Asias He as...@redhat.com writes: scsi.c includes vhost.c which uses memcpy_fromiovec. This patch fixes this build failure. From Randy Dunlap: ''' on x86_64: ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined! It needs to depend on NET since net/core/ provides that function. ''' Proper fix please. --verbose please ;-) Making VHOST_SCSI depends on NET looks weird but this is because vhost core depends on it. A bunch of patches are cleaning this up. Since MST wanted do the vhost.ko split up in 3.11, plus your WIP vringh work, so I wanted the fix for 3.10 as minimum as possible. Other users are using memcpy_fromiovec and friends outside net. It seems a good idea to put it in a util library. e.g. crypto/algif_skcipher.c which also depends on NET for it. Though I can't see why you thought this was a good idea. Nonetheless, I shan't highlight why: I have far too much respect for your intellects and abilities. No, don't thank me! Interesting. Rusty. -- Asias -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Thu, May 16, 2013 at 09:05:38AM +0930, Rusty Russell wrote: Nicholas A. Bellinger n...@linux-iscsi.org writes: On Wed, 2013-05-15 at 14:47 +0930, Rusty Russell wrote: Asias He as...@redhat.com writes: scsi.c includes vhost.c which uses memcpy_fromiovec. This patch fixes this build failure. From Randy Dunlap: ''' on x86_64: ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined! It needs to depend on NET since net/core/ provides that function. ''' Proper fix please. Though I can't see why you thought this was a good idea. Nonetheless, I shan't highlight why: I have far too much respect for your intellects and abilities. No, don't thank me! Hi Rusty Asias, I assume you mean something like the following patch to allow kbuild to work when VHOST_NET + VHOST_SCSI are both enabled and sharing vhost.o, yes..? No, that's a separate issue. memcpy_fromiovec() has nothing to do with networking: that was just the first user. Note that crypto/algif_skcipher.c also uses it. The obvious answer is to move it into lib/. That's true. I also want this. OTOH making vhost_scsi depend on CONFIG_NET is breathtakingly lazy. I expect better from experienced kernel hackers :( But do you think moving the memcpy_fromiovec stuff is a 3.10 material? Rusty. -- Asias -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
From: Rusty Russell ru...@rustcorp.com.au Date: Thu, 16 May 2013 09:05:38 +0930 memcpy_fromiovec() has nothing to do with networking: that was just the first user. Note that crypto/algif_skcipher.c also uses it. The obvious answer is to move it into lib/. +1 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
Asias He as...@redhat.com writes:
On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
scsi.c includes vhost.c which uses memcpy_fromiovec.
This patch fixes this build failure.
From Randy Dunlap:
'''
on x86_64:
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
It needs to depend on NET since net/core/ provides that function.
'''
Proper fix please.
--verbose please ;-)
Making VHOST_SCSI depends on NET looks weird but this is because vhost
core depends on it. A bunch of patches are cleaning this up. Since MST
wanted do the vhost.ko split up in 3.11, plus your WIP vringh work, so I
wanted the fix for 3.10 as minimum as possible.
If this isn't the only symbol causing the problem, then this should be
mentioned in the changelog. If it is, it should be fixed: we have
plenty of time for that.
Either way, your commit message or the commit itself needs to justify
it!
Other users are using memcpy_fromiovec and friends outside net. It seems
a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
which also depends on NET for it.
Though I can't see why you thought this was a good idea. Nonetheless, I
shan't highlight why: I have far too much respect for your intellects
and abilities.
No, don't thank me!
Interesting.
Heh... I originally wrote an explanation, then found it a bit insulting:
I knew I didn't need to tell you :)
How's this?
From: Rusty Russell ru...@rustcorp.com.au
Subject: Hoist memcpy_fromiovec into lib/
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
That function is only present with CONFIG_NET. Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.
socket.h already include uio.h, so no callers need updating.
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 428c37a..7266775 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -305,7 +305,6 @@ struct ucred {
extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct
ucred *ucred);
-extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len);
extern int csum_partial_copy_fromiovecend(unsigned char *kdata,
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 629aaf5..21628d3 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -35,4 +35,6 @@ static inline size_t iov_length(const struct iovec *iov,
unsigned long nr_segs)
}
unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t to);
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
#endif
diff --git a/lib/Makefile b/lib/Makefile
index e9c52e1..2377211 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -9,7 +9,7 @@ endif
lib-y := ctype.o string.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o dump_stack.o timerqueue.o\
-idr.o int_sqrt.o extable.o \
+idr.o int_sqrt.o extable.o iovec.o \
sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
diff --git a/lib/iovec.c b/lib/iovec.c
new file mode 100644
index 000..632c5ea
--- /dev/null
+++ b/lib/iovec.c
@@ -0,0 +1,29 @@
+#include linux/uaccess.h
+#include linux/export.h
+#include linux/uio.h
+
+/*
+ * Copy iovec to kernel. Returns -EFAULT on error.
+ *
+ * Note: this modifies the original iovec.
+ */
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
+{
+ while (len 0) {
+ if (iov-iov_len) {
+ int copy = min_t(unsigned int, len, iov-iov_len);
+ if (copy_from_user(kdata, iov-iov_base, copy))
+ return -EFAULT;
+ len -= copy;
+ kdata += copy;
+ iov-iov_base += copy;
+ iov-iov_len -= copy;
+ }
+ iov++;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(memcpy_fromiovec);
+
diff --git a/net/core/iovec.c b/net/core/iovec.c
index 7e7aeb0..d81257f 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -125,31 +125,6 @@ int memcpy_toiovecend(const struct iovec *iov, unsigned
char *kdata,
EXPORT_SYMBOL(memcpy_toiovecend);
/*
- * Copy iovec to kernel. Returns -EFAULT on error.
- *
- * Note: this modifies the original iovec.
- */
-
-int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
-{
- while (len 0) {
- if (iov-iov_len) {
- int copy = min_t(unsigned int, len, iov-iov_len);
-
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
[]
Other users are using memcpy_fromiovec and friends outside net. It seems
a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
which also depends on NET for it.
[]
Subject: Hoist memcpy_fromiovec into lib/
You'll need the friends memcpy_toiovec too.
$ git grep -E \bmemcpy\w+iovec\w*
crypto/algif_hash.c:err = memcpy_toiovec(msg-msg_iov, ctx-result, len);
crypto/algif_skcipher.c:err =
memcpy_fromiovec(page_address(sg_page(sg)) +
crypto/algif_skcipher.c:err =
memcpy_fromiovec(page_address(sg_page(sg + i)),
drivers/dma/iovlock.c:#include net/tcp.h /* for memcpy_toiovec */
drivers/dma/iovlock.c: return memcpy_toiovec(iov, kdata, len);
drivers/dma/iovlock.c: err = memcpy_toiovec(iov, vaddr + offset, len);
drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len),
msg-msg_iov, len)) {
drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
memcpy_fromiovec((u8 *)va + page_o
drivers/misc/vmw_vmci/vmci_queue_pair.c:err =
memcpy_toiovec(iov, (u8 *)va + pag
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec
On Thu, May 16, 2013 at 01:04:58PM +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
Asias He as...@redhat.com writes:
scsi.c includes vhost.c which uses memcpy_fromiovec.
This patch fixes this build failure.
From Randy Dunlap:
'''
on x86_64:
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
It needs to depend on NET since net/core/ provides that function.
'''
Proper fix please.
--verbose please ;-)
Making VHOST_SCSI depends on NET looks weird but this is because vhost
core depends on it. A bunch of patches are cleaning this up. Since MST
wanted do the vhost.ko split up in 3.11, plus your WIP vringh work, so I
wanted the fix for 3.10 as minimum as possible.
If this isn't the only symbol causing the problem, then this should be
mentioned in the changelog. If it is, it should be fixed: we have
plenty of time for that.
Either way, your commit message or the commit itself needs to justify
it!
memcpy_fromiovec is the only one causing the problem.
Other users are using memcpy_fromiovec and friends outside net. It seems
a good idea to put it in a util library. e.g. crypto/algif_skcipher.c
which also depends on NET for it.
Though I can't see why you thought this was a good idea. Nonetheless, I
shan't highlight why: I have far too much respect for your intellects
and abilities.
No, don't thank me!
Interesting.
Heh... I originally wrote an explanation, then found it a bit insulting:
I knew I didn't need to tell you :)
;-)
How's this?
Looks good and the commit log is more informative.
The
memcpy_toiovec
memcpy_toiovecend
memcpy_fromiovec
memcpy_fromiovecend
are all not net specific.
How about move them all to lib/ ?
Also need to make sure all the callers have uio.h included. e.g.
drivers/dma/iovlock.c
From: Rusty Russell ru...@rustcorp.com.au
Subject: Hoist memcpy_fromiovec into lib/
ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
That function is only present with CONFIG_NET. Turns out that
crypto/algif_skcipher.c also uses that outside net, but it actually
needs sockets anyway.
socket.h already include uio.h, so no callers need updating.
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 428c37a..7266775 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -305,7 +305,6 @@ struct ucred {
extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct
ucred *ucred);
-extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int
len);
extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len);
extern int csum_partial_copy_fromiovecend(unsigned char *kdata,
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 629aaf5..21628d3 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -35,4 +35,6 @@ static inline size_t iov_length(const struct iovec *iov,
unsigned long nr_segs)
}
unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t
to);
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
#endif
diff --git a/lib/Makefile b/lib/Makefile
index e9c52e1..2377211 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -9,7 +9,7 @@ endif
lib-y := ctype.o string.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o dump_stack.o timerqueue.o\
- idr.o int_sqrt.o extable.o \
+ idr.o int_sqrt.o extable.o iovec.o \
sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
diff --git a/lib/iovec.c b/lib/iovec.c
new file mode 100644
index 000..632c5ea
--- /dev/null
+++ b/lib/iovec.c
@@ -0,0 +1,29 @@
+#include linux/uaccess.h
+#include linux/export.h
+#include linux/uio.h
+
+/*
+ * Copy iovec to kernel. Returns -EFAULT on error.
+ *
+ * Note: this modifies the original iovec.
+ */
+
+int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
+{
+ while (len 0) {
+ if (iov-iov_len) {
+ int copy = min_t(unsigned int, len, iov-iov_len);
+ if (copy_from_user(kdata, iov-iov_base, copy))
+ return -EFAULT;
+ len -= copy;
+ kdata += copy;
+ iov-iov_base += copy;
+ iov-iov_len -= copy;
+ }
+ iov++;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(memcpy_fromiovec);
+
diff --git a/net/core/iovec.c b/net/core/iovec.c
index 7e7aeb0..d81257f 100644
---
Re: [PATCH 2/2] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock()
On Wed, May 15, 2013 at 11:36:02AM -0700, Sanjay Lal wrote: On May 15, 2013, at 10:30 AM, Gleb Natapov wrote: On Wed, May 15, 2013 at 09:54:24AM -0700, David Daney wrote: On 05/15/2013 08:54 AM, Sanjay Lal wrote: On May 14, 2013, at 2:27 AM, Gleb Natapov wrote: +EXPORT_SYMBOL(min_low_pfn); /* defined by bootmem.c, but not exported by generic code */ + What you need this for? It is not used anywhere in this patch and by mips/kvm code in general. I did some digging around myself, since the linker keeps complaining that it can't find min_low_pfn when compiling the KVM module. It seems that it is indirectly pulled in by the cache management functions. If it is really needed, then the export should probably be done at the site of the min_low_pfn definition, not in some random architecture file. Definitely. We cannot snick it here like that. Please drop it from this patch. I did export min_low_pfn where it was defined (in .../mm/bootmem.c) as part of the original patch set. It conflicted with the ia64/metag ports. min_low_pfn is exported in arch/ia64/kernel/ia64_ksyms.c and in arch/metag/kernel/metag_ksyms.c. There was some chatter about this when the KVM/MIPS code ended up in linux-next. From what I can gather, the maintainers for the other architectures agreed that exporting this symbol in bootmem.c was fine and should flow from the MIPS tree. I'll do that as part of v2 of the patch set. Make it a separate patch and send it to linux-kernel and linux...@kvack.org and affected arch maintainers. Or you can add export to arch/mips/kernel/mips_ksyms.c and ask Ralf to take it. I can take it via kvm tree with Ralf's ack too. In the commit message have a good explanation why it is needed please. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
