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

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1



>>> On 15.08.17 at 13:00, <roger.pau@xxxxxxxxxx> wrote:
> On Tue, Aug 15, 2017 at 10:55:10AM +0100, Roger Pau Monné wrote:
>> On Mon, Aug 14, 2017 at 02:08:56PM +0200, Andreas Kinzler wrote:
>> > On Mon, 14 Aug 2017 13:56:58 +0200, Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> > wrote:
>> > > > > I defined XEN_PT_LOGGING_ENABLED in xen_pt.h as requested without the
>> > > > > "hack" patch. Log is attached. Does it help?
>> > > > It tells me that there's nothing unexpected on that side. As I think I
>> > > > had indicated before, we really need to see both sides (qemu and
>> > > > hypervisor), as part of the MSI-X handling lives in Xen. And for the
>> > > > hypervisor side it is unlikely that we'll be able to get away without
>> > > > a debugging patch. I am intending to make such available to you in
>> > > > case you can't do so yourself, but I can't currently predict when I'll
>> > > > get to it.
>> > > I think the problem is that pci_msi_conf_write_intercept is failing to
>> > > unmask the entries when MSI-X is enabled with entries already
>> > > configured, but this will require some debugging patch as Jan said.
>> > > Following the MSI-X code is quite complicated, this split brain
>> > > between Xen and QEMU makes it quite hard. I can try to come up with a
>> > > patch later.
>> > 
>> > I can try some debug patches although my workload is very high at the
>> > moment. It would help me quite a bit if the debug patches were suitable for
>> > the stable 4.8 tree.
>> 
>> Hello,
>> 
>> Could you please try the patch below and paste the output you get on
>> the Xen console?
>> 
>> Jan, AFAICT (but I have to admit it's not easy to follow the code at
>> all), the following series of events will cause the MSIX entries to
>> not be unmasked:
>> 
>> 1. Guest configures the MSIX table entries and unmasks each of them.
>> 2. Guest enables MSIX.
>> 
>> This will cause the entries to remain masked, because QEMU will only
>> register the PIRQs and bind them when the MSI-X enable bit is set,
>> instead of doing it for each write to the MSIX table.
>> 
>> I guess one way to solve this would be to force QEMU to call
>> xen_pt_msix_update_one in pci_msix_write once the entry is unmasked,
>> even if MSIX is not enabled. I can prepare a patch for that.
> 
> So here is the patch for QEMU, if you don't mind giving it a try. I'm
> not really sure this is correct, since it will force Xen to enable
> MSIX in order to configure the entries, while the guest will still
> have MSIX disabled, but might we worth giving it a try.

But that's not a debugging patch then, but one trying a (guessed?)
solution. A debugging patch would not alter functionality (unless a
clear problem with a clear solution was found), but rather log state
in an extended fashion.

Jan

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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