search for: phys_to_virt

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present...

...ointer to image of ROM > + * > + * The caller is responsible for removing the mapping with iounmap() > */ > void __iomem *pci_platform_rom(struct pci_dev *pdev, size_t *size) > { > if (pdev->rom && pdev->romlen) { > *size = pdev->romlen; > - return phys_to_virt((phys_addr_t)pdev->rom); > + return ioremap(pdev->rom, pdev->romlen); > } What is the value of this helper over just open coding an ioremap of pdev->rom in the callers?

...chliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page...

...chliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page...

...chliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page...

...chliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page...

Hi Christoph, Thanks for your comments. I'm also replying here to your comments on the previous series. On Tuesday, March 17, 2020 10:28:35 AM EDT Christoph Hellwig wrote: > Any reason drivers can't just use pci_map_rom instead? which already > does the right thing? Some machines don't expose the video BIOS in the PCI BAR and instead only make it available via EFI boot

On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > On some EFI systems, the video BIOS is provided by the EFI firmware. The > boot stub code stores the physical address of the ROM image in pdev->rom. > Currently we attempt to access this pointer using phys_to_virt(), which > doesn't work with CONFIG_HIGHMEM. > > On these systems, attempting to load the radeon module on a x86_32 kernel > can result in the following: > > BUG: unable to handle page fault for address: 3e8ed03c > #PF: supervisor read access in kernel mode >...

...> <Christian.Koenig at amd.com>; Zhou, David(ChunMing) > <David1.Zhou at amd.com>; Matthew Garrett > <matthewgarrett at google.com>; Ben Skeggs <bskeggs at redhat.com>; > Christoph Hellwig <hch at lst.de> > Subject: Re: [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform > ROM > > On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > > On some EFI systems, the video BIOS is provided by the EFI firmware. > > The boot stub code stores the physical address of the ROM image in pdev- > >rom. > > Currently we...

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page fault for address: 3e8ed03c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present...

...turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > > -> dma_map_page > > -> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Mayb...

...turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > > -> dma_map_page > > -> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Mayb...

...Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Changes in v2: - Add iounmap() call in nouveau - Update function comment for pci_platform_rom() - Minor changes to commit messages Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use ioremap(), not phys_to_virt() for platform ROM drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 11 ++++++++++- drivers/gpu/drm/radeon/radeon_bios.c | 12 ++++++++---- drivers/pci/rom.c | 9 ++++++--- 4 fil...

This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use ioremap(), not phys_to_virt() for platform ROM drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 11 ++++++++++- drivers/gpu/drm/radeon/radeon_bios.c | 12 ++++++++---- drivers/pci/rom.c | 9 ++++++--- 4 fil...

...dma_ops? The breakage is not Xen related (except that Xen turns dma_ops on). The original message from Peng was: vring_map_one_sg -> vring_use_dma_api -> dma_map_page -> __swiotlb_map_page ->swiotlb_map_page ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must be missing something. Maybe it is because it has to do with RPMesg? > >...

...dma_ops? The breakage is not Xen related (except that Xen turns dma_ops on). The original message from Peng was: vring_map_one_sg -> vring_use_dma_api -> dma_map_page -> __swiotlb_map_page ->swiotlb_map_page ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must be missing something. Maybe it is because it has to do with RPMesg? > >...

...nstruct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa) return eptp; } +static void vmx_construct_eptp_with_index(struct kvm_vcpu *vcpu, + unsigned short view) +{ + struct vcpu_vmx *vmx = to_vmx(vcpu); + u64 *eptp_list = NULL; + + if (!vmx->eptp_list_pg) + return; + + eptp_list = phys_to_virt(page_to_phys(vmx->eptp_list_pg)); + + if (!eptp_list) + return; + + eptp_list[view] = construct_eptp(vcpu, + vcpu->arch.mmu->root_hpa_altviews[view]); +} + +static void vmx_construct_eptp_list(struct kvm_vcpu *vcpu) +{ + unsigned short view; + + for (view = 0; view < KVM_MAX_EPT_VIE...

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect descriptors even if we have plenty of space in the ring. This means that we take a performance hit at all times due to the overhead of creating indirect descriptors. Instead, use it only after we're below a configurable offset. Signed-off-by: Sasha Levin <levinsasha928 at gmail.com> --- drivers/block/virtio_blk.c

...l message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I m...