[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 3/3] xen/vpci: msix: move read/write call to MSI-X PBA entry to arch file


  • To: Rahul Singh <rahul.singh@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 24 Feb 2022 16:18:31 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7beCHNBUSqMcb2FL3XYvk/0DsVD+l0nbGSQWf8CZ6uQ=; b=BWCJEjmYpD2rY0fASX9It+OU7Jbdki6rYOyqB8nijMZrayys7tHIWlhvPX8ObqpN01/MdErb6uR4bfpNQeUtesK6oQ6endgp7b8h0mGKbIDkg7BcF5T4UQlvZY/WW+NHP3TpoSvZ6uS4grhnpoqVDcebUSwxFZpL7azVcEsblXYafomzpZQKHxME0/eSVuXcm6OyOAar9XZRIAvfF94hwO89NRWHUNeyB84hFsWMqpyjA5iliCo2RUGF4hjRiZif+QpMvBbxVfJITd9SLYPPYa7PsJsYAbAG7OjXsz9S+QD3JBcSwZDR/KB5RfYW4tZpNo20aAlBHHrTCnkGyA3Pjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ducSf9fkaRqFtwuCqa1v/sSXXkRBvrRWI7vjWtWcuSvxut+czL97QEGeS82vDyosamAcgmaX62g3dc0mrjTP5Fo0dNwlnyn8JEMFxWvQDmMPMriDRtC7DMjetjZnRQXmzui+sZz5wafjGbHGJaSMHCf2dglO5u7lPR2CuLQ/Q62C8PjHYvIcQT1tXLvk4xuRy1TiORLkMhdpFr7Xr6pIzWw9aE3VEJO8YJkJ4j1C9LW4bqWqdz1pCn25flDK0tRkF7b4cLCQNVf5TpmGKy4Z+mECx6DiLXyNVkYDqbZMZeurOW34FS981J+v8h6Tu+O5/GkbCbqsGDq9Jd/uXvQZLA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: bertrand.marquis@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 24 Feb 2022 15:18:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.02.2022 16:25, Rahul Singh wrote:
> {read,write}{l,q} function argument is different for ARM and x86.
> ARM {read,wrie}(l,q} function argument is pointer whereas X86
> {read,wrie}(l,q} function argument is address itself.

I'm afraid I don't follow: x86 has

#define readl(x) (*(volatile uint32_t *)(x))
#define readq(x) (*(volatile uint64_t *)(x))

That's no different from Arm64:

#define readl(c)                ({ u32 __v = readl_relaxed(c); __iormb(); __v; 
})

#define readl_relaxed(c)        ({ u32 __v = le32_to_cpu((__force 
__le32)__raw_readl(c)); __v; })

static inline u32 __raw_readl(const volatile void __iomem *addr)

The difference is whether the address is expressed as a pointer, or
_may_ also be expressed as unsigned long. IOW the x86 variant is
perfectly fine to be passed e.g. a void * (preferably qualified
appropriately). The conversion from unsigned long to a pointer type
is actually expressed ...

> @@ -170,31 +170,7 @@ bool vpci_msix_read(struct vpci_msix *msix, unsigned 
> long addr,
>          return true;
>  
>      if ( VMSIX_ADDR_IN_RANGE(addr, msix->pdev->vpci, VPCI_MSIX_PBA) )
> -    {
> -        /*
> -         * Access to PBA.
> -         *
> -         * TODO: note that this relies on having the PBA identity mapped to 
> the
> -         * guest address space. If this changes the address will need to be
> -         * translated.
> -         */
> -        switch ( len )
> -        {
> -        case 4:
> -            *data = readl(addr);
> -            break;
> -
> -        case 8:
> -            *data = readq(addr);
> -            break;
> -
> -        default:
> -            ASSERT_UNREACHABLE();
> -            break;
> -        }

... in the comment ahead of this switch() (and the assumption is likely
wrong for DomU).

But then, Roger: What "identity mapped" is meant here? Surely not GVA ->
GPA, but rather GPA -> HPA? The address here is a guest physical one,
but read{l,q}() act on (host) virtual addresses. This would have been
easier to notice as wrong if read{l,q}() weren't allowing unsigned long
arguments to be passed to them.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.