Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 6月, 2020 1 次提交
  3. 09 6月, 2020 2 次提交
  5. 07 6月, 2020 2 次提交
  7. 05 6月, 2020 5 次提交
  9. 02 6月, 2020 2 次提交
    • M
      vhost: revert "vhost: disable for OABI" · 213e7721
      由 Michael S. Tsirkin 提交于 
      This reverts commit d085eb8c ("vhost: disable for OABI")
With commit "virtio: force spec specified alignment on types"
in place, we force proper alignment for all structures,
so there's no longer a reason to blacklist OABI.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      213e7721
    • M
      virtio: force spec specified alignment on types · a865e420
      由 Michael S. Tsirkin 提交于 
      The ring element addresses are passed between components with different
alignments assumptions. Thus, if guest/userspace selects a pointer and
host then gets and dereferences it, we might need to decrease the
compiler-selected alignment to prevent compiler on the host from
assuming pointer is aligned.

This actually triggers on ARM with -mabi=apcs-gnu - which is a
deprecated configuration, but it seems safer to handle this
generally.

Note that userspace that allocates the memory is actually OK and does
not need to be fixed, but userspace that gets it from guest or another
process does need to be fixed. The later doesn't generally talk to the
kernel so while it might be buggy it's not talking to the kernel in the
buggy way - it's just using the header in the buggy way - so fixing
header and asking userspace to recompile is the best we can do.

I verified that the produced kernel binary on x86 is exactly identical
before and after the change.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
      a865e420
  11. 27 5月, 2020 1 次提交
  13. 15 5月, 2020 2 次提交
  15. 02 5月, 2020 1 次提交
    • J
      vhost: vsock: kick send_pkt worker once device is started · 0b841030
      由 Jia He 提交于 
      Ning Bo reported an abnormal 2-second gap when booting Kata container [1].
The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of
connecting from the client side. The vhost vsock client tries to connect
an initializing virtio vsock server.

The abnormal flow looks like:
host-userspace           vhost vsock                       guest vsock
==============           ===========                       ============
connect()     -------->  vhost_transport_send_pkt_work()   initializing
   |                     vq->private_data==NULL
   |                     will not be queued
   V
schedule_timeout(2s)
                         vhost_vsock_start()  <---------   device ready
                         set vq->private_data

wait for 2s and failed
connect() again          vq->private_data!=NULL         recv connecting pkt

Details:
1. Host userspace sends a connect pkt, at that time, guest vsock is under
   initializing, hence the vhost_vsock_start has not been called. So
   vq->private_data==NULL, and the pkt is not been queued to send to guest
2. Then it sleeps for 2s
3. After guest vsock finishes initializing, vq->private_data is set
4. When host userspace wakes up after 2s, send connecting pkt again,
   everything is fine.

As suggested by Stefano Garzarella, this fixes it by additional kicking the
send_pkt worker in vhost_vsock_start once the virtio device is started. This
makes the pending pkt sent again.

After this patch, kata-runtime (with vsock enabled) boot time is reduced
from 3s to 1s on a ThunderX2 arm64 server.

[1] https://github.com/kata-containers/runtime/issues/1917Reported-by: NNing Bo <n.b@live.com>
Suggested-by: NStefano Garzarella <sgarzare@redhat.com>
Signed-off-by: NJia He <justin.he@arm.com>
Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
      0b841030
  17. 28 4月, 2020 2 次提交
  19. 20 4月, 2020 1 次提交
    • M
      vhost: disable for OABI · d085eb8c
      由 Michael S. Tsirkin 提交于 
      vhost is currently broken on the some ARM configs.

The reason is that the ring element addresses are passed between
components with different alignments assumptions. Thus, if
guest selects a pointer and host then gets and dereferences
it, then alignment assumed by the host's compiler might be
greater than the actual alignment of the pointer.
compiler on the host from assuming pointer is aligned.

This actually triggers on ARM with -mabi=apcs-gnu - which is a
deprecated configuration. With this OABI, compiler assumes that
all structures are 4 byte aligned - which is stronger than
virtio guarantees for available and used rings, which are
merely 2 bytes. Thus a guest without -mabi=apcs-gnu running
on top of host with -mabi=apcs-gnu will be broken.

The correct fix is to force alignment of structures - however
that is an intrusive fix that's best deferred until the next release.

We didn't previously support such ancient systems at all - this surfaced
after vdpa support prompted removing dependency of vhost on
VIRTULIZATION. So for now, let's just add something along the lines of

	depends on !ARM || AEABI

to the virtio Kconfig declaration, and add a comment that it has to do
with struct member alignment.

Note: we can't make VHOST and VHOST_RING themselves have
a dependency since these are selected. Add a new symbol for that.

We should be able to drop this dependency down the road.

Fixes: 20c384f1 ("vhost: refine vhost and vringh kconfig")
Suggested-by: NArd Biesheuvel <ardb@kernel.org>
Suggested-by: NRichard Earnshaw <Richard.Earnshaw@arm.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      d085eb8c
  21. 17 4月, 2020 5 次提交
  23. 02 4月, 2020 5 次提交
  25. 23 2月, 2020 1 次提交
  27. 08 12月, 2019 1 次提交
  29. 05 12月, 2019 1 次提交
  31. 15 11月, 2019 5 次提交
  33. 28 10月, 2019 1 次提交
  35. 23 10月, 2019 1 次提交
  37. 13 10月, 2019 1 次提交