All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Auger Eric <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v2] vfio_pci: Enable memory accesses before calling pci_map_rom
Date: Thu, 14 Feb 2019 13:16:28 -0700	[thread overview]
Message-ID: <20190214131628.54ca06fc@w520.home> (raw)
In-Reply-To: <015103e3-c317-22f3-e209-f5ccf890bafb@redhat.com>

On Thu, 14 Feb 2019 19:27:15 +0100
Auger Eric <eric.auger@redhat.com> wrote:

> Hi Alex,
> 
> On 2/13/19 6:52 PM, Alex Williamson wrote:
> > On Wed, 13 Feb 2019 12:06:10 +0100
> > Eric Auger <eric.auger@redhat.com> wrote:
> >   
> >> pci_map_rom/pci_get_rom_size() performs memory access in the ROM.
> >> In case the Memory Space accesses were disabled, readw() is likely to
> >> crash the host with a synchronous external abort (aarch64).  
> > 
> > As implied in response to Konrad, the likeliness really depends on the
> > whole platform, not just the CPU architecture.  It's a class of
> > problems that depends on OS control or error handling, which we simply
> > don't have on many systems.  But we can fix this instance of it.  
> 
> Agreed, I just hit this issue on one specific aarch64 machine
> >   
> >> In case memory accesses were disabled, re-enable them before the call
> >> and disable them back again just after.
> >>
> >> Signed-off-by: Eric Auger <eric.auger@redhat.com>  
> > 
> > This has been around since the beginning, but maybe a Fixes tag would
> > be useful:
> > 
> > Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")  
> OK
> >   
> >>
> >> ---
> >>
> >> v1 -> v2:
> >> - also re-enable in case of error
> >> ---
> >>  drivers/vfio/pci/vfio_pci.c | 17 ++++++++++++++++-
> >>  1 file changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> >> index ff60bd1ea587..721aa55424a4 100644
> >> --- a/drivers/vfio/pci/vfio_pci.c
> >> +++ b/drivers/vfio/pci/vfio_pci.c
> >> @@ -706,8 +706,10 @@ static long vfio_pci_ioctl(void *device_data,
> >>  			break;
> >>  		case VFIO_PCI_ROM_REGION_INDEX:
> >>  		{
> >> +			bool mem_access_disabled;
> >>  			void __iomem *io;
> >>  			size_t size;
> >> +			u16 cmd;
> >>  
> >>  			info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index);
> >>  			info.flags = 0;
> >> @@ -723,15 +725,28 @@ static long vfio_pci_ioctl(void *device_data,
> >>  					break;
> >>  			}
> >>  
> >> +			pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> >> +			mem_access_disabled = !(cmd & PCI_COMMAND_MEMORY);
> >> +			if (mem_access_disabled) {
> >> +				cmd |= PCI_COMMAND_MEMORY;
> >> +				pci_write_config_word(pdev, PCI_COMMAND, cmd);
> >> +			}
> >> +
> >>  			/* Is it really there? */
> >>  			io = pci_map_rom(pdev, &size);
> >>  			if (!io || !size) {
> >>  				info.size = 0;
> >> -				break;
> >> +				goto rom_info_out;
> >>  			}
> >>  			pci_unmap_rom(pdev, io);
> >>  
> >>  			info.flags = VFIO_REGION_INFO_FLAG_READ;
> >> +rom_info_out:
> >> +			if (mem_access_disabled) {
> >> +				cmd &= ~PCI_COMMAND_MEMORY;
> >> +				pci_write_config_word(pdev, PCI_COMMAND, cmd);
> >> +			}
> >> +
> >>  			break;
> >>  		}
> >>  		case VFIO_PCI_VGA_REGION_INDEX:  
> > 
> > I don't think we need to be so timid about the command register and we
> > can also avoid the goto by modifying the test (testing io and size in
> > the original is probably overly paranoid), perhaps simply:  
> Yes looks fine.
> 
> Do you want to respin or do you prefer I do?

Please take it, test it, and repost it, I haven't tested it at all.
Thanks,

Alex

      reply	other threads:[~2019-02-14 20:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 11:06 [PATCH v2] vfio_pci: Enable memory accesses before calling pci_map_rom Eric Auger
2019-02-13 17:52 ` Alex Williamson
2019-02-14 18:27   ` Auger Eric
2019-02-14 20:16     ` Alex Williamson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190214131628.54ca06fc@w520.home \
    --to=alex.williamson@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.