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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 25 Oct 2020 09:49:03 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'David Woodhouse' <dwmw2@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>
CC:     kvm <kvm@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "joro@...tes.org" <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "maz@...terjones.org" <maz@...terjones.org>,
        Dexuan Cui <decui@...rosoft.com>
Subject: RE: [PATCH v3 17/35] x86/pci/xen: Use msi_msg shadow structs

From: David Woodhouse
> Sent: 24 October 2020 22:35
> 
> From: Thomas Gleixner <tglx@...utronix.de>
> 
> Use the msi_msg shadow structs and compose the message with named bitfields
> instead of the unreadable macro maze.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
> ---
>  arch/x86/pci/xen.c | 26 +++++++++++---------------
>  1 file changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index c552cd2d0632..3d41a09c2c14 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -152,7 +152,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
> 
>  #if defined(CONFIG_PCI_MSI)
>  #include <linux/msi.h>
> -#include <asm/msidef.h>
> 
>  struct xen_pci_frontend_ops *xen_pci_frontend;
>  EXPORT_SYMBOL_GPL(xen_pci_frontend);
> @@ -210,23 +209,20 @@ static int xen_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  	return ret;
>  }
> 
> -#define XEN_PIRQ_MSI_DATA  (MSI_DATA_TRIGGER_EDGE | \
> -		MSI_DATA_LEVEL_ASSERT | (3 << 8) | MSI_DATA_VECTOR(0))
> -
>  static void xen_msi_compose_msg(struct pci_dev *pdev, unsigned int pirq,
>  		struct msi_msg *msg)
>  {
> -	/* We set vector == 0 to tell the hypervisor we don't care about it,
> -	 * but we want a pirq setup instead.
> -	 * We use the dest_id field to pass the pirq that we want. */
> -	msg->address_hi = MSI_ADDR_BASE_HI | MSI_ADDR_EXT_DEST_ID(pirq);
> -	msg->address_lo =
> -		MSI_ADDR_BASE_LO |
> -		MSI_ADDR_DEST_MODE_PHYSICAL |
> -		MSI_ADDR_REDIRECTION_CPU |
> -		MSI_ADDR_DEST_ID(pirq);
> -
> -	msg->data = XEN_PIRQ_MSI_DATA;
> +	/*
> +	 * We set vector == 0 to tell the hypervisor we don't care about
> +	 * it, but we want a pirq setup instead.  We use the dest_id fields
> +	 * to pass the pirq that we want.
> +	 */
> +	memset(msg, 0, sizeof(*msg));
> +	msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
> +	msg->arch_addr_hi.destid_8_31 = pirq >> 8;
> +	msg->arch_addr_lo.destid_0_7 = pirq & 0xFF;
> +	msg->arch_addr_lo.base_address = X86_MSI_BASE_ADDRESS_LOW;
> +	msg->arch_data.delivery_mode = APIC_DELIVERY_MODE_EXTINT;
>  }

Just looking at a random one of these patches...

Does the compiler manage to optimise that reasonably?
Or does it generate a lot of shifts and masks as each
bitfield is set?

The code generation for bitfields is often a lot worse
that that for |= setting bits in a word.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ