Date: Thu, 15 Nov 2018 18:32:08 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 203874] [patch] MSI/MSI-X interrupts don't work in VMware virtual machines Message-ID: <bug-203874-27103-X9k54QofZL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-203874-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-203874-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203874 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #12 from John Baldwin <jhb@FreeBSD.org> --- Hmm, I don't recall which issue we ran into with VMWare. We have had some issues with Xen hypervisors that might be related. They had to do with how= the hypervisor cached MSI-X table entries and that it didn't notice updates to = the table that FreeBSD's kernel performed because it assumed the table was not modified once MSI-X was enabled in the capability register. Commits related to those issues are r302181 + r302635 and r310806. >From the thread about igb(4) that was quoted, it sounds like it might be a similar issue where VMWare might be assuming that MSI-X tables are only upd= ated in a particular order. FreeBSD follows a scheme where it marks all the tab= le entries as disabled and then enables MSI-X in the capability register and t= hen writes individual table entries as the driver calls bus_setup_intr(). This means that the table can change while MSI-X is enabled. A table entry might also be written multiple times if a device driver moves an interrupt to a different CPU than the one chosen by the system. In real hardware this wor= ks fine as the hardware checks the table to compose the MSI message before sen= ding each message. Hypervisors might choose to cache the table since reading the actual table might be too expensive. However, in that case hypervisors hav= e to trap all writes to the table and update their cached copy for each write. = The Xen issues had to do with Xen assuming it could ignore writes made while MS= I-X was active since Linux writes the whole table and then enables MSI-X. I wo= uld start by seeing if you have a shadow copy of the MSI-X table and if you make assumptions about which writes to that table have to be trapped to update t= he shadow table. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-203874-27103-X9k54QofZL>