On Thu, 2012-05-24 at 18:53 -0300, Jan Kiszka wrote:
> On 2012-05-24 18:39, Thomas Gleixner wrote:
> > On Thu, 24 May 2012, Alex Williamson wrote:
> >> On Thu, 2012-05-24 at 18:02 +0100, Richard Weinberger wrote:
> >>> + 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?
> >
> > The problem with the current implementation is that it only changes
> > the routing if the msi entry goes from masked to unmasked state.
> >
> > Linux does not mask the entries on affinity changes and never did,
> > neither for MSI nor for MSI-X.
> >
> > I know it's probably not according to the spec, but we can't fix that
> > retroactively.
>
> For MSI, this is allowed. For MSI-X, this would clearly be a Linux bug,
> waiting for hardware to dislike this spec violation.
>
> However, if this is the current behavior of such a prominent guest, I
> guess we have to stop optimizing the QEMU MSI-X code that it only
> updates routings on mask changes. Possibly other OSes get this wrong too...
>
> Thanks, for the clarification. Should go into the changelog.
Hmm, if Linux didn't mask MSIX before updating vectors it'd not only be
a spec violation, but my testing of the recent changes to fix MSIX
vector updates for exactly this would have failed...
} else if (msix_masked(&orig) && !msix_masked(entry)) {
... update vector...
So I'm not entirely sure I believe that. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
