linux-kernel - Re: [PATCH v5 1/1] vfio/nvgpu: Add vfio pci variant module for grace hopper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BY5PR12MB3763993E153A8A1B9E73A3D0B005A@BY5PR12MB3763.namprd12.prod.outlook.com>
Date:   Mon, 31 Jul 2023 14:32:26 +0000
From:   Ankit Agrawal <ankita@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     Aniket Agashe <aniketa@...dia.com>, Neo Jia <cjia@...dia.com>,
        Kirti Wankhede <kwankhede@...dia.com>,
        "Tarun Gupta (SW-GPU)" <targupta@...dia.com>,
        Vikram Sethi <vsethi@...dia.com>,
        Andy Currid <acurrid@...dia.com>,
        Alistair Popple <apopple@...dia.com>,
        John Hubbard <jhubbard@...dia.com>,
        Dan Williams <danw@...dia.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/1] vfio/nvgpu: Add vfio pci variant module for grace
 hopper

>> >
>> > Just to confirm, the ask is to just update the comment to reflect the behavior,
>> > right? (I missed to do that in this posting). Because we do redirect the call to
>> > vfio_pci_core_read() here which will perform the read that is within the device
>> > region. The read response to synthesize -1 is only for the range that is outside
>> > the device memory region.
>>
>> This doesn't seem right, vfio_pci_core_read() will use pci_iomap() to
>> get a mapping which will be a DEVICE mapping, this will make the
>> access incoherent with any cachable mappings.
>
> Right, but also vfio_pci_core_read() doesn't know anything about this
> virtual BAR2, so any in-range BAR2 accesses will error the same as
> trying to access an unimplemented BAR.  It's not just the comment,
> there's no code here to handle a read(2) from in-bound BAR2 accesses.
> Thanks,

Got it, I would do memremap() to the target device memory physical address 
here. The memremap() and the data copy would be done to only the number 
of bytes asked with the read/write operation.

Will post that with the next version shortly.