[Your response didn't make it to the list, I think because it's some non-plaintext encoding that is rejected by the list (see http://vger.kernel.org/majordomo-info.html)] On Wed, Nov 30, 2016 at 11:56 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Bjorn Helgaas >> Sent: 29 November 2016 04:15 >> If we update a VF BAR while it's enabled, there are two potential problems: >> >> 1) Any driver that's using the VF has a cached BAR value that is stale >> after the update, and >> >> 2) We can't update 64-bit BARs atomically, so the intermediate state >> (new lower dword with old upper dword) may conflict with another >> device, and an access by a driver unrelated to the VF may cause a bus >> error. > > Can the high word be first set to a value that is invalid (ie a 4G block > that has no valid PCIe slaves) before updating the low word and finally > the correct high word. > > Note that the address only has to be outside the range that the bridge > forwards onto that specific bus. Maybe, but I think that's getting way too complicated. I think we should just think of it as a higher level bug if we're trying to update an enabled BAR. We might have to live with that scenario for standard BARs because firmware might have enabled it for us, and things might break if we disable it, but I don't think we should try to make it work for VF BARs. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
