All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jag Raman <jag.raman@oracle.com>
Cc: "eduardo@habkost.net" <eduardo@habkost.net>,
	"Elena Ufimtseva" <elena.ufimtseva@oracle.com>,
	"John Johnson" <john.g.johnson@oracle.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"bleal@redhat.com" <bleal@redhat.com>,
	"john.levon@nutanix.com" <john.levon@nutanix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"quintela@redhat.com" <quintela@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Kanth Ghatraju" <kanth.ghatraju@oracle.com>,
	"thanos.makatos@nutanix.com" <thanos.makatos@nutanix.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"eblake@redhat.com" <eblake@redhat.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [PATCH v7 14/17] vfio-user: handle PCI BAR accesses
Date: Wed, 30 Mar 2022 11:05:59 +0100	[thread overview]
Message-ID: <YkQrh5pWniHTT1LK@stefanha-x1.localdomain> (raw)
In-Reply-To: <45272D4A-0625-446A-804E-3211F2D91B81@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

On Tue, Mar 29, 2022 at 03:51:17PM +0000, Jag Raman wrote:
> 
> 
> > On Mar 29, 2022, at 8:50 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > 
> > On Fri, Mar 25, 2022 at 03:19:43PM -0400, Jagannathan Raman wrote:
> >> @@ -324,6 +325,170 @@ static void dma_unregister(vfu_ctx_t *vfu_ctx, vfu_dma_info_t *info)
> >>     trace_vfu_dma_unregister((uint64_t)info->iova.iov_base);
> >> }
> >> 
> >> +static size_t vfu_object_bar_rw(PCIDevice *pci_dev, int pci_bar,
> >> +                                hwaddr offset, char * const buf,
> >> +                                hwaddr len, const bool is_write)
> >> +{
> >> +    uint8_t *ptr = (uint8_t *)buf;
> >> +    uint8_t *ram_ptr = NULL;
> >> +    bool release_lock = false;
> >> +    MemoryRegionSection section = { 0 };
> >> +    MemoryRegion *mr = NULL;
> >> +    int access_size;
> >> +    hwaddr size = 0;
> >> +    MemTxResult result;
> >> +    uint64_t val;
> >> +
> >> +    section = memory_region_find(pci_dev->io_regions[pci_bar].memory,
> >> +                                 offset, len);
> >> +
> >> +    if (!section.mr) {
> >> +        return 0;
> >> +    }
> >> +
> >> +    mr = section.mr;
> >> +    offset = section.offset_within_region;
> >> +
> >> +    if (is_write && mr->readonly) {
> >> +        warn_report("vfu: attempting to write to readonly region in "
> >> +                    "bar %d - [0x%"PRIx64" - 0x%"PRIx64"]",
> >> +                    pci_bar, offset, (offset + len));
> >> +        return 0;
> > 
> > A mr reference is leaked. The return statement can be replaced with goto
> > exit.
> 
> OK.
> 
> > 
> >> +    }
> >> +
> >> +    if (memory_access_is_direct(mr, is_write)) {
> >> +        /**
> >> +         * Some devices expose a PCI expansion ROM, which could be buffer
> >> +         * based as compared to other regions which are primarily based on
> >> +         * MemoryRegionOps. memory_region_find() would already check
> >> +         * for buffer overflow, we don't need to repeat it here.
> >> +         */
> >> +        ram_ptr = memory_region_get_ram_ptr(mr);
> >> +
> >> +        size = len;
> > 
> > This looks like it will access beyond the end of ram_ptr when
> > section.size < len after memory_region_find() returns.
> 
> OK - will will handle shorter sections returned by memory_region_find().
> 
> > 
> >> +
> >> +        if (is_write) {
> >> +            memcpy((ram_ptr + offset), buf, size);
> >> +        } else {
> >> +            memcpy(buf, (ram_ptr + offset), size);
> >> +        }
> >> +
> >> +        goto exit;
> > 
> > What happens when the access spans two adjacent MemoryRegions? I think
> > the while (len > 0) loop is needed even in the memory_access_is_direct()
> > case so we perform the full access instead of truncating it.
> 
> OK - this should be covered by the shorter section handling above.

No, shorter section handling truncates that access. I think the caller
expects all len bytes to be accessed, not just the first few bytes?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-03-30 10:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25 19:19 [PATCH v7 00/17] vfio-user server in QEMU Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 01/17] tests/avocado: Specify target VM argument to helper routines Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 02/17] qdev: unplug blocker for devices Jagannathan Raman
2022-03-29 10:08   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 03/17] remote/machine: add HotplugHandler for remote machine Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 04/17] remote/machine: add vfio-user property Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 05/17] configure: require cmake 3.19 or newer Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 06/17] vfio-user: build library Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 07/17] vfio-user: define vfio-user-server object Jagannathan Raman
2022-03-29 10:21   ` Stefan Hajnoczi
2022-03-29 14:03     ` Jag Raman
2022-03-25 19:19 ` [PATCH v7 08/17] vfio-user: instantiate vfio-user context Jagannathan Raman
2022-03-29 10:26   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 09/17] vfio-user: find and init PCI device Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 10/17] vfio-user: run vfio-user context Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 11/17] vfio-user: handle PCI config space accesses Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 12/17] vfio-user: IOMMU support for remote device Jagannathan Raman
2022-03-29 12:35   ` Stefan Hajnoczi
2022-03-29 14:12     ` Jag Raman
2022-03-29 14:48       ` Stefan Hajnoczi
2022-03-29 19:58         ` Jag Raman
2022-03-30 10:04           ` Stefan Hajnoczi
2022-03-30 12:53             ` Peter Xu
2022-03-30 16:08               ` Stefan Hajnoczi
2022-03-30 17:13                 ` Peter Xu
2022-03-31  9:47                   ` Stefan Hajnoczi
2022-03-31 12:41                     ` Peter Xu
2022-04-13 14:37                       ` Igor Mammedov
2022-04-13 19:08                         ` Peter Xu
2022-04-19  8:48                           ` Igor Mammedov
2022-04-13 14:25   ` Igor Mammedov
2022-04-13 18:25     ` Jag Raman
2022-04-13 21:59       ` Jag Raman
2022-03-25 19:19 ` [PATCH v7 13/17] vfio-user: handle DMA mappings Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 14/17] vfio-user: handle PCI BAR accesses Jagannathan Raman
2022-03-29 12:50   ` Stefan Hajnoczi
2022-03-29 15:51     ` Jag Raman
2022-03-30 10:05       ` Stefan Hajnoczi [this message]
2022-03-30 14:46         ` Jag Raman
2022-03-30 16:06           ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 15/17] vfio-user: handle device interrupts Jagannathan Raman
2022-03-25 19:19 ` [PATCH v7 16/17] vfio-user: handle reset of remote device Jagannathan Raman
2022-03-29 14:46   ` Stefan Hajnoczi
2022-03-25 19:19 ` [PATCH v7 17/17] vfio-user: avocado tests for vfio-user Jagannathan Raman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YkQrh5pWniHTT1LK@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=bleal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=elena.ufimtseva@oracle.com \
    --cc=f4bug@amsat.org \
    --cc=jag.raman@oracle.com \
    --cc=john.g.johnson@oracle.com \
    --cc=john.levon@nutanix.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=thanos.makatos@nutanix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.