lkml.org 
[lkml]   [2021]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC 10/20] iommu/iommufd: Add IOMMU_DEVICE_GET_INFO
    Date
    > From: Jason Gunthorpe <jgg@nvidia.com>
    > Sent: Tuesday, October 26, 2021 7:35 AM
    >
    > On Fri, Oct 22, 2021 at 03:08:06AM +0000, Tian, Kevin wrote:
    >
    > > > I have no idea what security model makes sense for wbinvd, that is the
    > > > major question you have to answer.
    > >
    > > wbinvd flushes the entire cache in local cpu. It's more a performance
    > > isolation problem but nothing can prevent it once the user is allowed
    > > to call this ioctl. This is the main reason why wbinvd is a privileged
    > > instruction and is emulated by kvm as a nop unless an assigned device
    > > has no-snoop requirement. alternatively the user may call clflush
    > > which is unprivileged and can invalidate a specific cache line, though
    > > not efficient for flushing a big buffer.
    > >
    > > One tricky thing is that the process might be scheduled to different
    > > cpus between writing buffers and calling wbinvd ioctl. Since wbvind
    > > only has local behavior, it requires the ioctl to call wbinvd on all
    > > cpus that this process has previously been scheduled on.
    >
    > That is such a hassle, you may want to re-open this with the kvm
    > people as it seems ARM also has different behavior between VM and
    > process here.
    >
    > The ideal is already not being met, so maybe we can keep special
    > casing cache ops?
    >

    will do.

    \
     
     \ /
      Last update: 2021-10-27 03:43    [W:3.963 / U:0.220 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site