public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Richard Weinberger <richard@nod.at>
Cc: kvm@vger.kernel.org, avi@redhat.com, mtosatti@redhat.com,
	tglx@linutronix.de
Subject: Re: [PATCH 2/2] Device assignment: Fix MSI IRQ affinity setting
Date: Thu, 24 May 2012 12:20:27 -0600	[thread overview]
Message-ID: <1337883627.4714.32.camel@ul30vt> (raw)
In-Reply-To: <1337878924-39069-2-git-send-email-richard@nod.at>

On Thu, 2012-05-24 at 18:02 +0100, Richard Weinberger wrote:
> MSI interrupt affinity setting on the guest ended always up on vcpu0,
> no matter what.
> IOW writes to /proc/irq/<IRQ>/smp_affinity are irgnored.
> This patch fixes the MSI IRQ routing and avoids the utter madness of
> tearing down and setting up the interrupt completely when this changes.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
>  hw/device-assignment.c |   73 ++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 70 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 09726f9..78d57c8 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -913,6 +913,50 @@ void assigned_dev_update_irqs(void)
>      }
>  }
>  
> +static void assigned_dev_update_msi_route(PCIDevice *pci_dev)
> +{
> +    AssignedDevice *adev = DO_UPCAST(AssignedDevice, dev, pci_dev);
> +    uint8_t ctrl_byte = pci_get_byte(pci_dev->config + pci_dev->msi_cap +
> +				     PCI_MSI_FLAGS);
> +    struct kvm_irq_routing_entry *old, new;
> +    KVMMsiMessage msg;
> +    int r;

Please follow qemu coding style for braces throughout.

> +
> +    if (!(ctrl_byte & PCI_MSI_FLAGS_ENABLE))
> +	    return;
> +
> +    msg.addr_lo =  pci_get_long(pci_dev->config + pci_dev->msi_cap +
> +				PCI_MSI_ADDRESS_LO);
> +    msg.addr_hi =  pci_get_long(pci_dev->config + pci_dev->msi_cap +
> +				PCI_MSI_ADDRESS_HI);

Odd, since we only expose a 32bit MSI capability to the guest...

> +    msg.data =  pci_get_long(pci_dev->config + pci_dev->msi_cap +
> +			     PCI_MSI_DATA_32);

Should be pci_get_word()

> +
> +    old = adev->entry;
> +    new = *old;
> +    new.u.msi.address_lo = msg.addr_lo;
> +    new.u.msi.address_hi = msg.addr_hi;
> +    new.u.msi.data = msg.data;
> +
> +    if (memcmp(old, &new, sizeof(new)) == 0)
> +        return;
> +
> +    r = kvm_update_routing_entry(old, &new);

How does this work?  old is now new, so kvm_update_routing_entry() is
never going to match to the existing entry if address_lo or data
actually change.

> +    if (r < 0) {
> +        fprintf(stderr, "%s: kvm_update_msi failed: %s\n", __func__,
> +                strerror(-r));
> +        exit(1);
> +    }
> +
> +    *old = new;

huh?

> +     r = kvm_irqchip_commit_routes(kvm_state);
> +     if (r) {
> +        fprintf(stderr, "%s: kvm_irqchip_commit_routes failed: %s\n", __func__,
> +                strerror(-r));
> +        exit(1);
> +     }
> +}
> +
>  static void assigned_dev_update_msi(PCIDevice *pci_dev)
>  {
>      struct kvm_assigned_irq assigned_irq_data;
> @@ -1116,6 +1160,14 @@ static uint32_t assigned_dev_pci_read_config(PCIDevice *pci_dev,
>      uint32_t virt_val = pci_default_read_config(pci_dev, address, len);
>      uint32_t real_val, emulate_mask, full_emulation_mask;
>  
> +    if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSI) {
> +        uint32_t msi_start = pci_dev->msi_cap;
> +        uint32_t msi_end = msi_start + PCI_MSI_DATA_64 + 3;
> +
> +	if (address >= msi_start && (address + len) < msi_end)

ranges_overlap() is meant for this.  We only expose a 32bit MSI cap, so
msi_end is wrong.

> +            return virt_val;
> +    }
> +
>      emulate_mask = 0;
>      memcpy(&emulate_mask, assigned_dev->emulate_config_read + address, len);
>      emulate_mask = le32_to_cpu(emulate_mask);
> @@ -1130,6 +1182,17 @@ static uint32_t assigned_dev_pci_read_config(PCIDevice *pci_dev,
>      }
>  }
>  
> +static void handle_cfg_write_msi(PCIDevice *pci_dev, AssignedDevice *adev)
> +{
> +    if (!kvm_enabled() || !kvm_irqchip_in_kernel())
> +	return;

Unnecessary, device assignment doesn't work otherwise.

> +
> +    if (adev->entry && (adev->irq_requested_type & KVM_DEV_IRQ_GUEST_MSI))

Should just be able to test irq_requested_type.

> +        assigned_dev_update_msi_route(pci_dev);
> +    else
> +        assigned_dev_update_msi(pci_dev);
> +}
> +
>  static void assigned_dev_pci_write_config(PCIDevice *pci_dev, uint32_t address,
>                                            uint32_t val, int len)
>  {
> @@ -1155,9 +1218,13 @@ static void assigned_dev_pci_write_config(PCIDevice *pci_dev, uint32_t address,
>          }
>      }
>      if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSI) {
> -        if (range_covers_byte(address, len,
> -                              pci_dev->msi_cap + PCI_MSI_FLAGS)) {
> -            assigned_dev_update_msi(pci_dev);
> +        uint32_t msi_start = pci_dev->msi_cap;
> +        uint32_t msi_end = msi_start + PCI_MSI_DATA_64 + 3;
> +
> +        if (address >= msi_start && (address + len) < msi_end) {

Use ranges_overlap() please, msi_end is wrong.

> +            if (address == msi_start + PCI_MSI_DATA_32)
> +                handle_cfg_write_msi(pci_dev, assigned_dev);

Why didn't we just use range_covers_byte(address, len, pci_dev->msi_cap
+ PCI_MSI_DATA_32) to start with?  But how does this handle the enable
bit?

> +            return;
>          }
>      }
>      if (assigned_dev->cap.available & ASSIGNED_DEVICE_CAP_MSIX) {

Thanks,

Alex


  reply	other threads:[~2012-05-24 18:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-24 17:02 [PATCH 1/2] Remove kvm_commit_irq_routes from error messages Richard Weinberger
2012-05-24 17:02 ` [PATCH 2/2] Device assignment: Fix MSI IRQ affinity setting Richard Weinberger
2012-05-24 18:20   ` Alex Williamson [this message]
     [not found]     ` <CAEMbtc+ycsC6u=CZ_Yg6C=WV=VqjA2uEDM5KWPM_7n3sZh_9Pw@mail.gmail.com>
2012-05-24 19:27       ` Richard Weinberger
2012-05-24 21:39     ` Thomas Gleixner
2012-05-24 21:53       ` Jan Kiszka
2012-05-24 22:11         ` Alex Williamson
2012-05-24 23:01           ` Thomas Gleixner
2012-05-24 23:23             ` Alex Williamson
2012-05-24 23:56               ` Thomas Gleixner
2012-05-25  2:37                 ` Jan Kiszka
2012-05-24 22:17         ` Michael S. Tsirkin
2012-05-24 23:06           ` Thomas Gleixner
2012-05-24 23:19             ` Thomas Gleixner
2012-05-24 22:05       ` Alex Williamson
2012-05-24 20:47   ` Jan Kiszka

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=1337883627.4714.32.camel@ul30vt \
    --to=alex.williamson@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=richard@nod.at \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox