On 2019/9/9 下午12:45, Michael S. Tsirkin wrote:
Since idx can be speculated, I guess we need array_index_nospec here?
So we have
ACQUIRE(mmu_lock)
get idx
RELEASE(mmu_lock)
ACQUIRE(mmu_lock)
read array[idx]
RELEASE(mmu_lock)
Then I think idx can't be speculated consider we've passed
On Mon, Sep 09, 2019 at 10:18:57AM +0800, Jason Wang wrote:
>
> On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
> > On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote:
> > > This is a rework on the commit 7f466032dc9e ("vhost: access vq
> > > metadata through kernel virtual address").
> > >
On 2019/9/9 上午10:18, Jason Wang wrote:
On a elder CPU Sandy Bridge without SMAP support. TX PPS doesn't see
any difference.
Why is not Kaby Lake with SMAP off the same as Sandy Bridge?
I don't know, I guess it was because the atomic is l
Sorry, I meant atomic costs less for Kaby Lake.
On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote:
This is a rework on the commit 7f466032dc9e ("vhost: access vq
metadata through kernel virtual address").
It was noticed that the copy_to/from_user() friends that was used to
access
On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote:
> This is a rework on the commit 7f466032dc9e ("vhost: access vq
> metadata through kernel virtual address").
>
> It was noticed that the copy_to/from_user() friends that was used to
> access virtqueue metdata tends to be very expensive
On 2019/9/6 上午11:21, Hillf Danton wrote:
On Thu, 5 Sep 2019 20:27:36 +0800 From: Jason Wang
+static void vhost_set_map_dirty(struct vhost_virtqueue *vq,
+ struct vhost_map *map, int index)
+{
+ struct vhost_uaddr *uaddr = >uaddrs[index];
+ int i;
This is a rework on the commit 7f466032dc9e ("vhost: access vq
metadata through kernel virtual address").
It was noticed that the copy_to/from_user() friends that was used to
access virtqueue metdata tends to be very expensive for dataplane
implementation like vhost since it involves lots of
7 matches
Mail list logo
