|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/4] xen/x86: Replace remaining mandatory barriers with SMP barriers
>>> On 16.08.17 at 13:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> There is no functional change. Xen currently assignes smp_* meaning to
> the non-smp_* barriers.
>
> All of these uses are just to deal with shared memory between multiple
> processors, so use the smp_*() which are the correct barriers for the
> purpose.
Taking this together with ...
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -390,9 +390,9 @@ void mwait_idle_with_hints(unsigned int eax, unsigned int
> ecx)
>
> if ( boot_cpu_has(X86_FEATURE_CLFLUSH_MONITOR) )
> {
> - mb();
> + smp_mb();
> clflush((void *)&mwait_wakeup(cpu));
> - mb();
> + smp_mb();
> }
See commit 48d32458bc ("x86, idle: add barriers to CLFLUSH
workaround") for why these better stay the way they are.
> @@ -755,10 +755,10 @@ void acpi_dead_idle(void)
> * instruction, hence memory fence is necessary to make sure all
> * load/store visible before flush cache line.
> */
> - mb();
> + smp_mb();
> clflush(mwait_ptr);
> __monitor(mwait_ptr, 0, 0);
> - mb();
> + smp_mb();
> __mwait(cx->address, 0);
... the comment the tail of which is in context here, I'm rather
surprised you convert these: They're there strictly for
correctness on a single processor (the need for prior memory
accesses to be visible isn't limited to the CPUs in the system).
In both cases, while smp_mb() and mb() are the same, I'd rather
keep the distinction at use sites with the assumption that the
smp_* ones would expand to just barrier() when !CONFIG_SMP (a
configuration we currently simply don't allow). The only alternative
I see would be to open-code the fences.
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -91,7 +91,7 @@ static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv,
> ioreq_t *p)
> {
> unsigned int state = p->state;
>
> - rmb();
> + smp_rmb();
> switch ( state )
> {
> case STATE_IOREQ_NONE:
> @@ -1327,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
> hvm_ioreq_server *s, ioreq_t *p)
> }
>
> /* Make the ioreq_t visible /before/ write_pointer. */
> - wmb();
> + smp_wmb();
> pg->ptrs.write_pointer += qw ? 2 : 1;
I agree with these changes, but it needs to be clear that their
counterparts cannot be smp_?mb().
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -976,10 +976,10 @@ static void __update_vcpu_system_time(struct vcpu *v,
> int force)
>
> /* 1. Update guest kernel version. */
> _u.version = u->version = version_update_begin(u->version);
> - wmb();
> + smp_wmb();
> /* 2. Update all other guest kernel fields. */
> *u = _u;
> - wmb();
> + smp_wmb();
> /* 3. Update guest kernel version. */
> u->version = version_update_end(u->version);
>
> @@ -1006,10 +1006,10 @@ bool update_secondary_system_time(struct vcpu *v,
> update_guest_memory_policy(v, &policy);
> return false;
> }
> - wmb();
> + smp_wmb();
> /* 2. Update all other userspace fields. */
> __copy_to_guest(user_u, u, 1);
> - wmb();
> + smp_wmb();
> /* 3. Update userspace version. */
> u->version = version_update_end(u->version);
> __copy_field_to_guest(user_u, u, version);
Same fore these.
So with the cpu_idle.c changes dropped or replaced by open-coded
fences
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |