On Tue, Sep 10, 2019 at 09:52:10AM +0800, Jason Wang wrote:
>
> On 2019/9/9 下午10:45, Michael S. Tsirkin wrote:
> > On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote:
> > > On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
> > > > iovec addresses coming from vhost are assumed to be
> > > > pre
On 2019/9/9 下午10:45, Michael S. Tsirkin wrote:
On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote:
On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address
On Thu, Sep 5, 2019 at 10:18 PM Gerd Hoffmann wrote:
>
> > +/* How many bytes left in this page. */
> > +static unsigned int rest_of_page(void *data)
> > +{
> > + return PAGE_SIZE - offset_in_page(data);
> > +}
>
> Not needed.
>
> > +/* Create sg_table from a vmalloc'd buffer. */
> > +static s
On 05/09/19 20:09, Jerome Glisse wrote:
> Not sure i understand, you are saying that the solution i outline above
> does not work ? If so then i think you are wrong, in the above solution
> the importing process mmap a device file and the resulting vma is then
> populated using insert_pfn() and con
On 06/09/19 10:54, Stefan Hajnoczi wrote:
> On Thu, Sep 05, 2019 at 06:19:28PM +, Matt Lupfer wrote:
>> The event handler calls scsi_scan_host() when events are missed, which
>> will hotplug new LUNs. However, this function won't remove any
>> unplugged LUNs. The result is that hotunplug does
On Mon, Sep 09, 2019 at 06:14:55PM +0200, Stefan Hajnoczi wrote:
> On Sun, Sep 08, 2019 at 07:53:55PM +0800, piaojun wrote:
> >
> >
> > On 2019/9/6 19:52, Miklos Szeredi wrote:
> > > On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi
> > > wrote:
> > >>
> > >> On Fri, Sep 06, 2019 at 10:15:14AM +0
On Sun, Sep 08, 2019 at 07:53:55PM +0800, piaojun wrote:
>
>
> On 2019/9/6 19:52, Miklos Szeredi wrote:
> > On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi wrote:
> >>
> >> On Fri, Sep 06, 2019 at 10:15:14AM +0200, Miklos Szeredi wrote:
> >>> On Thu, Sep 5, 2019 at 9:49 PM Vivek Goyal wrote:
>
On Fri, Sep 06, 2019 at 09:51:31AM -0400, Vivek Goyal wrote:
> On Fri, Sep 06, 2019 at 01:05:34PM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 05, 2019 at 03:48:57PM -0400, Vivek Goyal wrote:
> > > It is possible that a mount is in progress and device is being removed at
> > > the same time. Use v
On Fri, Sep 06, 2019 at 09:50:32AM -0400, Vivek Goyal wrote:
> On Fri, Sep 06, 2019 at 01:03:09PM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote:
> > > This object is used both by fuse_connection as well virt device. So make
> > > this object reference
On Fri, Sep 06, 2019 at 10:18:49AM -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 06, 2019 at 10:17:05AM -0400, Vivek Goyal wrote:
> > On Fri, Sep 06, 2019 at 11:52:10AM +0100, Stefan Hajnoczi wrote:
> > > On Thu, Sep 05, 2019 at 03:48:49PM -0400, Vivek Goyal wrote:
> > > > +static void virtio_fs_d
On Sun, Sep 08, 2019 at 07:10:03PM +0800, piaojun wrote:
>
>
> On 2019/9/6 3:48, Vivek Goyal wrote:
> > This object is used both by fuse_connection as well virt device. So make
> > this object reference counted and that makes it easy to define life cycle
> > of the object.
> >
> > Now deivce can
On Mon, Sep 09, 2019 at 03:19:55PM +0800, Jason Wang wrote:
>
> On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
> > iovec addresses coming from vhost are assumed to be
> > pre-validated, but in fact can be speculated to a value
> > out of range.
> >
> > Userspace address are later validated with ar
The separation between GEM VRAM objects and and the memory manager
is artificial, as they are only used with each other. Copying both
implementations into the same file is a first step to simplifying
the code.
This patch only moves code without functional changes.
Signed-off-by: Thomas Zimmermann
The statement's condition is always true.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 73e81e3a8724..13717ae65d
VRAM MM and GEM VRAM buffer objects are only used with each other;
connected via 3 function pointers. Simplifiy this code by making the
memory manager call the rsp. functions from the BOs directly; and
remove the functions from he BO's public interface.
Signed-off-by: Thomas Zimmermann
---
drive
The init, cleanup and mmap functions of VRAM MM are only used internally.
Remove them from the public interface.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 38 ---
include/drm/drm_gem_vram_helper.h | 7 -
2 files changed, 5 inser
VRAM MM and GEM VRAM are only used with each other. This patch set
moves VRAM MM into GEM VRAM source files and cleans up the helper's
public interface.
Thomas Zimmermann (4):
drm/vram: Move VRAM memory manager to GEM VRAM implementation
drm/vram: Have VRAM MM call GEM VRAM functions directly
Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER
> in config DRM_VRAM_HELPER, we have to select them on the vram users
> instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/Kconfig | 2 --
> drivers
On Mon, Sep 09, 2019 at 03:18:01PM +0800, Jason Wang wrote:
>
> On 2019/9/6 下午9:15, David Miller wrote:
> > From: Jason Wang
> > Date: Fri, 6 Sep 2019 18:02:35 +0800
> >
> > > On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
> > > > I think you should apply the revert this cycle and rebase the other
>
On Mon, 9 Sep 2019 from Gerd Hoffmann
>
> Hmm, I think the patch is wrong.
Hmm...it should have added change only in the error path, leaving locks
for drivers to release if job is done with no error returned.
> As far I know it is the qxl drivers's
> job to call ttm_eu_backoff_reservation().
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 RELEA
On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these address
On 2019/9/6 下午9:15, David Miller wrote:
From: Jason Wang
Date: Fri, 6 Sep 2019 18:02:35 +0800
On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
I think you should apply the revert this cycle and rebase the other
patch for next..
Jason
Yes, the plan is to revert in this release cycle.
Then you s
On 2019/9/6 下午9:46, Michael S. Tsirkin wrote:
On Thu, Sep 05, 2019 at 08:27:35PM +0800, Jason Wang wrote:
It was reported that metadata acceleration introduces several issues,
so this patch reverts commit ff466032dc9e5a61217f22ea34b2df932786bbfc,
73f628ec9e6bcc45b77c53fe6d0c0ec55eaf82af and
0b4
Hi,
On Mon, 9 Sep 2019 from Gerd Hoffmann
>
> Hmm, I think the patch is wrong. As far I know it is the qxl drivers's
> job to call ttm_eu_backoff_reservation(). Doing that automatically in
> ttm will most likely break other ttm users.
>
Perhaps.
>So I guess the call is missing in the qxl drive
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
Rename the embedded struct vma_offset_manager, new name is _vma_manager.
ttm_bo_device.vma_manager changed to a pointer.
The ttm_bo_device_init() function gets an additional vma_manager
argument which allows to initialize ttm with a different vma manag
26 matches
Mail list logo
