On 2020-09-22 18:40, Alex Williamson wrote:
On Mon, 21 Sep 2020 08:43:29 -0400
Matthew Rosato <mjrosato@xxxxxxxxxxxxx> wrote:
On 9/10/20 10:59 AM, Matthew Rosato wrote:
While it is true that devices with is_virtfn=1 will have a Memory Space
Enable bit that is hard-wired to 0, this is not the only case where we
see this behavior -- For example some bare-metal hypervisors lack
Memory Space Enable bit emulation for devices not setting is_virtfn
(s390). Fix this by instead checking for the newly-added
no_command_memory bit which directly denotes the need for
PCI_COMMAND_MEMORY emulation in vfio.
Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Signed-off-by: Matthew Rosato <mjrosato@xxxxxxxxxxxxx>
Reviewed-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
Reviewed-by: Pierre Morel <pmorel@xxxxxxxxxxxxx>
Polite ping on this patch as the other 2 have now received maintainer
ACKs or reviews. I'm concerned about this popping up in distros as
abafbc551fdd was a CVE fix. Related, see question from the cover:
- Restored the fixes tag to patch 3 (but the other 2 patches are
now pre-reqs -- cc stable 5.8?)
I've got these queued in my local branch which I'll push to next for
v5.10. I'm thinking that perhaps the right thing would be to add the
fixes tag to all three patches, otherwise I could see that the PCI/VF
change might get picked as a dependency, but not the s390 specific one.
Does this sound correct to everyone? Thanks,
Alex
sound correct for me.
Thanks.
Pierre
--
Pierre Morel
IBM Lab Boeblingen
