Jan Beulich
2009-Jun-10 14:36 UTC
[Xen-devel] [PATCH 1/3] x86: properly handle vcpu-to-pcpu mask conversion
This is one of the prerequisites to extend to number of vCPU-s the
hypervisor can support per guest.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- 2009-06-10.orig/xen/arch/x86/mm.c 2009-06-05 11:59:48.000000000 +0200
+++ 2009-06-10/xen/arch/x86/mm.c 2009-06-10 10:46:17.000000000 +0200
@@ -2565,29 +2565,41 @@ static int set_foreigndom(domid_t domid)
return okay;
}
-static inline cpumask_t vcpumask_to_pcpumask(
- struct domain *d, unsigned long vmask)
+static inline int vcpumask_to_pcpumask(
+ struct domain *d, XEN_GUEST_HANDLE(const_void) bmap, cpumask_t *pmask)
{
- unsigned int vcpu_id;
- cpumask_t pmask = CPU_MASK_NONE;
+ unsigned int vcpu_id, vcpu_bias, offs;
+ unsigned long vmask;
struct vcpu *v;
+ bool_t is_native = !is_pv_32on64_domain(d);
- /*
- * Callers copy only a single guest-sized longword from the guest.
- * This must be wide enough to reference all VCPUs. Worst case is 32 bits.
- */
- BUILD_BUG_ON(MAX_VIRT_CPUS > 32);
-
- while ( vmask != 0 )
+ cpus_clear(*pmask);
+ for ( vmask = 0, offs = 0; ; ++offs)
{
- vcpu_id = find_first_set_bit(vmask);
- vmask &= ~(1UL << vcpu_id);
- if ( (vcpu_id < MAX_VIRT_CPUS) &&
- ((v = d->vcpu[vcpu_id]) != NULL) )
- cpus_or(pmask, pmask, v->vcpu_dirty_cpumask);
- }
+ vcpu_bias = offs * (is_native ? BITS_PER_LONG : 32);
+ if ( vcpu_bias >= MAX_VIRT_CPUS )
+ return 0;
+
+ if ( unlikely(is_native ?
+ copy_from_guest_offset(&vmask, bmap, offs, 1) :
+ copy_from_guest_offset((unsigned int *)&vmask, bmap,
+ offs, 1)) )
+ {
+ cpus_clear(*pmask);
+ return -EFAULT;
+ }
- return pmask;
+ while ( vmask )
+ {
+ vcpu_id = find_first_set_bit(vmask);
+ vmask &= ~(1UL << vcpu_id);
+ vcpu_id += vcpu_bias;
+ if ( (vcpu_id >= MAX_VIRT_CPUS) )
+ return 0;
+ if ( ((v = d->vcpu[vcpu_id]) != NULL) )
+ cpus_or(*pmask, *pmask, v->vcpu_dirty_cpumask);
+ }
+ }
}
#ifdef __i386__
@@ -2816,14 +2828,13 @@ int do_mmuext_op(
case MMUEXT_TLB_FLUSH_MULTI:
case MMUEXT_INVLPG_MULTI:
{
- unsigned long vmask;
cpumask_t pmask;
- if ( unlikely(copy_from_guest(&vmask, op.arg2.vcpumask, 1)) )
+
+ if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask,
&pmask)) )
{
okay = 0;
break;
}
- pmask = vcpumask_to_pcpumask(d, vmask);
if ( op.cmd == MMUEXT_TLB_FLUSH_MULTI )
flush_tlb_mask(&pmask);
else
@@ -3630,7 +3641,7 @@ int do_update_va_mapping(unsigned long v
struct domain *d = v->domain;
struct page_info *gl1pg;
l1_pgentry_t *pl1e;
- unsigned long vmask, bmap_ptr, gl1mfn;
+ unsigned long bmap_ptr, gl1mfn;
cpumask_t pmask;
int rc;
@@ -3682,11 +3693,9 @@ int do_update_va_mapping(unsigned long v
default:
if ( this_cpu(percpu_mm_info).deferred_ops & DOP_FLUSH_ALL_TLBS
)
break;
- if ( unlikely(!is_pv_32on64_domain(d) ?
- get_user(vmask, (unsigned long *)bmap_ptr) :
- get_user(vmask, (unsigned int *)bmap_ptr)) )
- rc = -EFAULT, vmask = 0;
- pmask = vcpumask_to_pcpumask(d, vmask);
+ rc = vcpumask_to_pcpumask(d, const_guest_handle_from_ptr(bmap_ptr,
+ void),
+ &pmask);
if ( cpu_isset(smp_processor_id(), pmask) )
this_cpu(percpu_mm_info).deferred_ops &= ~DOP_FLUSH_TLB;
flush_tlb_mask(&pmask);
@@ -3710,11 +3719,9 @@ int do_update_va_mapping(unsigned long v
flush_tlb_one_mask(&d->domain_dirty_cpumask, va);
break;
default:
- if ( unlikely(!is_pv_32on64_domain(d) ?
- get_user(vmask, (unsigned long *)bmap_ptr) :
- get_user(vmask, (unsigned int *)bmap_ptr)) )
- rc = -EFAULT, vmask = 0;
- pmask = vcpumask_to_pcpumask(d, vmask);
+ rc = vcpumask_to_pcpumask(d, const_guest_handle_from_ptr(bmap_ptr,
+ void),
+ &pmask);
if ( this_cpu(percpu_mm_info).deferred_ops & DOP_FLUSH_TLB )
cpu_clear(smp_processor_id(), pmask);
flush_tlb_one_mask(&pmask, va);
--- 2009-06-10.orig/xen/arch/x86/x86_64/compat/mm.c 2009-01-15
10:02:31.000000000 +0100
+++ 2009-06-10/xen/arch/x86/x86_64/compat/mm.c 2009-06-10 10:46:17.000000000
+0200
@@ -278,18 +278,7 @@ int compat_mmuext_op(XEN_GUEST_HANDLE(mm
}
#define XLAT_mmuext_op_HNDL_arg2_vcpumask(_d_, _s_) \
- do \
- { \
- unsigned int vcpumask; \
- if ( i < --limit ) \
- { \
- (_d_)->arg2.vcpumask.p = (void *)(nat_ops.p + limit); \
- if ( copy_from_compat(&vcpumask,
(_s_)->arg2.vcpumask, 1) == 0 ) \
- *(unsigned long *)(_d_)->arg2.vcpumask.p = vcpumask;
\
- else \
- rc = -EFAULT; \
- } \
- } while(0)
+ guest_from_compat_handle((_d_)->arg2.vcpumask,
(_s_)->arg2.vcpumask)
XLAT_mmuext_op(nat_op, &cmp_op);
#undef XLAT_mmuext_op_HNDL_arg2_vcpumask
--- 2009-06-10.orig/xen/include/asm-x86/guest_access.h 2008-09-08
12:57:38.000000000 +0200
+++ 2009-06-10/xen/include/asm-x86/guest_access.h 2009-06-10 10:46:17.000000000
+0200
@@ -45,6 +45,8 @@
#define guest_handle_from_ptr(ptr, type) \
((XEN_GUEST_HANDLE(type)) { (type *)ptr })
+#define const_guest_handle_from_ptr(ptr, type) \
+ ((XEN_GUEST_HANDLE(const_##type)) { (const type *)ptr })
/*
* Copy an array of objects to guest context via a guest handle,
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jun-10 16:48 UTC
Re: [Xen-devel] [PATCH 1/3] x86: properly handle vcpu-to-pcpu mask conversion
On 10/06/2009 17:36, "Jan Beulich" <JBeulich@novell.com> wrote:> This is one of the prerequisites to extend to number of vCPU-s the > hypervisor can support per guest. > > Signed-off-by: Jan Beulich <jbeulich@novell.com>Okay, I didn''t see patch 0/3 that summarises the overall approach, nor patch 3/3 which would actually make greater numbers of VCPUs usable. Obviously that is the most interesting patch since it is a change, or at least extension, of guest interface. Also it''s what makes patches 1/3 and 2/3 actually useful. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2009-Jun-15 07:20 UTC
Re: [Xen-devel] [PATCH 1/3] x86: properly handle vcpu-to-pcpu maskconversion
>>> Keir Fraser <keir.fraser@eu.citrix.com> 10.06.09 18:48 >>> >On 10/06/2009 17:36, "Jan Beulich" <JBeulich@novell.com> wrote: > >> This is one of the prerequisites to extend to number of vCPU-s the >> hypervisor can support per guest. >> >> Signed-off-by: Jan Beulich <jbeulich@novell.com> > >Okay, I didn''t see patch 0/3 that summarises the overall approach, nor patchI didn''t send a summary, as there was nothing that really needs summarizing.>3/3 which would actually make greater numbers of VCPUs usable. Obviously >that is the most interesting patch since it is a change, or at least >extension, of guest interface. Also it''s what makes patches 1/3 and 2/3 >actually useful.A glitch of the list server? I see the mail on the xen-devel archives. And I know that I frequently get mails that the list server appears to have delayed for hours or even days. But if you still didn''t get it, I can certainly re-send it. Just let me know... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jun-15 07:42 UTC
Re: [Xen-devel] [PATCH 1/3] x86: properly handle vcpu-to-pcpu maskconversion
On 15/06/2009 08:20, "Jan Beulich" <JBeulich@novell.com> wrote:>> 3/3 which would actually make greater numbers of VCPUs usable. Obviously >> that is the most interesting patch since it is a change, or at least >> extension, of guest interface. Also it''s what makes patches 1/3 and 2/3 >> actually useful. > > A glitch of the list server? I see the mail on the xen-devel archives. And I > know that I frequently get mails that the list server appears to have delayed > for hours or even days. But if you still didn''t get it, I can certainly > re-send > it. Just let me know...Found it. I seem to have a random spam filter. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel