All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>, qemu-devel@nongnu.org
Cc: Alexey Kardashevskiy <aik@au1.ibm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH for-5.1] xhci: fix valid.max_access_size to access address registers
Date: Tue, 21 Jul 2020 11:17:57 +0200	[thread overview]
Message-ID: <65c1e6b9-523b-99ec-39eb-00ce59399ccf@redhat.com> (raw)
In-Reply-To: <20200721083322.90651-1-lvivier@redhat.com>

On 7/21/20 10:33 AM, Laurent Vivier wrote:
> QEMU XHCI advertises AC64 (64-bit addressing) but doesn't allow
> 64-bit mode access in "runtime" and "operational" MemoryRegionOps.
> 
> Set the max_access_size based on sizeof(dma_addr_t) as AC64 is set.
> 
> XHCI specs:
> "If the xHC supports 64-bit addressing (AC64 = ‘1’), then software
> should write 64-bit registers using only Qword accesses.  If a
> system is incapable of issuing Qword accesses, then writes to the
> 64-bit address fields shall be performed using 2 Dword accesses;
> low Dword-first, high-Dword second.  If the xHC supports 32-bit
> addressing (AC64 = ‘0’), then the high Dword of registers containing
> 64-bit address fields are unused and software should write addresses
> using only Dword accesses"

You only describe the WRITE path. Is the READ path similar?

> 
> The problem has been detected with SLOF, as linux kernel always accesses
> registers using 32-bit access even if AC64 is set and revealed by
> 5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"")
> 
> Suggested-by: Alexey Kardashevskiy <aik@au1.ibm.com>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  hw/usb/hcd-xhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
> index b330e36fe6cc..67a18fe2b64c 100644
> --- a/hw/usb/hcd-xhci.c
> +++ b/hw/usb/hcd-xhci.c
> @@ -3184,7 +3184,7 @@ static const MemoryRegionOps xhci_oper_ops = {
>      .read = xhci_oper_read,
>      .write = xhci_oper_write,
>      .valid.min_access_size = 4,
> -    .valid.max_access_size = 4,
> +    .valid.max_access_size = sizeof(dma_addr_t),
>      .endianness = DEVICE_LITTLE_ENDIAN,
>  };
>  
> @@ -3200,7 +3200,7 @@ static const MemoryRegionOps xhci_runtime_ops = {
>      .read = xhci_runtime_read,
>      .write = xhci_runtime_write,
>      .valid.min_access_size = 4,
> -    .valid.max_access_size = 4,
> +    .valid.max_access_size = sizeof(dma_addr_t),
>      .endianness = DEVICE_LITTLE_ENDIAN,
>  };

I wonder if we shouldn't check the access size now, something like:

bool xhci_check_access_size(void *opaque, hwaddr addr,
                            unsigned size, bool is_write,
                            MemTxAttrs attrs);
{
    XHCIState *xhci = opaque;

    /* FIXME only for is_write??? */
    return xhci->ac64 || size == 4;
}

And add to both MemoryRegionOps:

       .accepts = xhci_check_access_size,



  reply	other threads:[~2020-07-21  9:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21  8:33 [PATCH for-5.1] xhci: fix valid.max_access_size to access address registers Laurent Vivier
2020-07-21  9:17 ` Philippe Mathieu-Daudé [this message]
2020-07-21 10:25   ` Laurent Vivier
2020-07-21 14:01     ` Gerd Hoffmann

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=65c1e6b9-523b-99ec-39eb-00ce59399ccf@redhat.com \
    --to=philmd@redhat.com \
    --cc=aik@au1.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=kraxel@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.