qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 6/6] vhost-user: support registering external


From: Liang, Cunming
Subject: Re: [Qemu-devel] [PATCH v3 6/6] vhost-user: support registering external host notifiers
Date: Thu, 19 Apr 2018 16:52:20 +0000


> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden
> Sent: Thursday, April 19, 2018 11:52 PM
> To: Michael S. Tsirkin <address@hidden>; Liang, Cunming
> <address@hidden>
> Cc: Bie, Tiwei <address@hidden>; address@hidden;
> address@hidden; address@hidden; address@hidden;
> address@hidden; Daly, Dan <address@hidden>; Tan, Jianfeng
> <address@hidden>; Wang, Zhihong <address@hidden>; Wang,
> Xiao W <address@hidden>
> Subject: Re: [PATCH v3 6/6] vhost-user: support registering external host
> notifiers
> 
> On 19/04/2018 17:42, Michael S. Tsirkin wrote:
> >> A compiler barrier is enough on strongly-ordered memory platform.
> >> As it doesn't re-order store, PCI device won't see a stale index
> >> value. But a weakly-ordered memory needs sfence.
> >
> > Oh you are right.
> >
> > So it's only needed for non-intel platforms or when packets are in WC
> > memory then. And I don't know whether dpdk ever puts packets in WC
> > memory.
> >
> > I guess we'll cross this bridge when we get to it.
> 
> Non-TSO architectures seem important...

I'm not familiar with Non-TSO, trying to understand the difference according to 
the feature set. Let's say non-TSO architectures do not set 'weak_barriers'. 
Then mandatory barrier is used for software. HW offload on that platform would 
choose different feature set against software? 
If it's not, essentially we're worried about live migration from a TSO to a 
non-TSO architectures platform?

> 
> Paolo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]