| Message ID | 9cfd038719fee7fcb01b8967ffcb23802bb75a0b.1586953651.git.havanur@amazon.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [XEN,v5] hvmloader: Enable MMIO and I/O decode, after all resource allocation | expand |
On 15.04.2020 14:27, Harsha Shamsundara Havanur wrote: > It was observed that PCI MMIO and/or IO BARs were programmed with > memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled, > during PCI setup phase. This resulted in incorrect memory mapping as > soon as the lower half of the 64 bit bar is programmed. > This displaced any RAM mappings under 4G. After the > upper half is programmed PCI memory mapping is restored to its > intended high mem location, but the RAM displaced is not restored. > The OS then continues to boot and function until it tries to access > the displaced RAM at which point it suffers a page fault and crashes. > > This patch address the issue by deferring enablement of memory and > I/O decode in command register until all the resources, like interrupts > I/O and/or MMIO BARs for all the PCI device functions are programmed, > in the descending order of memory requested. > > Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> with one further adjustment: > @@ -120,6 +121,13 @@ void pci_setup(void) > */ > bool allow_memory_relocate = 1; > > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != > + PCI_COMMAND_IO); > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != > + PCI_COMMAND_MEMORY); > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER != > + PCI_COMMAND_MASTER); Indentation here still looks wrong, despite me having given you the precise form to use in reply to v4. This can be taken care of while committing (if no other need for a v6 arises), but it would have been nice if you had done this as indicated. Jan
On Wed, 2020-04-15 at 16:14 +0200, Jan Beulich wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > On 15.04.2020 14:27, Harsha Shamsundara Havanur wrote: > > It was observed that PCI MMIO and/or IO BARs were programmed with > > memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) > > enabled, > > during PCI setup phase. This resulted in incorrect memory mapping > > as > > soon as the lower half of the 64 bit bar is programmed. > > This displaced any RAM mappings under 4G. After the > > upper half is programmed PCI memory mapping is restored to its > > intended high mem location, but the RAM displaced is not restored. > > The OS then continues to boot and function until it tries to access > > the displaced RAM at which point it suffers a page fault and > > crashes. > > > > This patch address the issue by deferring enablement of memory and > > I/O decode in command register until all the resources, like > > interrupts > > I/O and/or MMIO BARs for all the PCI device functions are > > programmed, > > in the descending order of memory requested. > > > > Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com> > > Reviewed-by: Jan Beulich <jbeulich@suse.com> > with one further adjustment: > > > @@ -120,6 +121,13 @@ void pci_setup(void) > > */ > > bool allow_memory_relocate = 1; > > > > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != > > + PCI_COMMAND_IO); > > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMOR > > Y != > > + PCI_COMMAND_MEMORY); > > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTE > > R != > > + PCI_COMMAND_MASTER); > > Indentation here still looks wrong, despite me having given you > the precise form to use in reply to v4. This can be taken care > of while committing (if no other need for a v6 arises), but it > would have been nice if you had done this as indicated. > This is due to my vimrc configuration. I will fix this while comitting to align second line to begin with typeof > Jan
> -----Original Message----- > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Harsha Shamsundara Havanur > Sent: 15 April 2020 13:28 > To: xen-devel@lists.xenproject.org > Cc: Wei Liu <wl@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Ian Jackson > <ian.jackson@eu.citrix.com>; Jan Beulich <jbeulich@suse.com>; Harsha Shamsundara Havanur > <havanur@amazon.com>; Roger Pau Monné <roger.pau@citrix.com> > Subject: [XEN PATCH v5] hvmloader: Enable MMIO and I/O decode, after all resource allocation > > It was observed that PCI MMIO and/or IO BARs were programmed with > memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled, > during PCI setup phase. This resulted in incorrect memory mapping as > soon as the lower half of the 64 bit bar is programmed. > This displaced any RAM mappings under 4G. After the > upper half is programmed PCI memory mapping is restored to its > intended high mem location, but the RAM displaced is not restored. > The OS then continues to boot and function until it tries to access > the displaced RAM at which point it suffers a page fault and crashes. > > This patch address the issue by deferring enablement of memory and > I/O decode in command register until all the resources, like interrupts > I/O and/or MMIO BARs for all the PCI device functions are programmed, > in the descending order of memory requested. > > Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com> > > --- > Changes in v5: > - Fix style and comment > - Enable Bus master for all valid device functions > > Changes in v4: > Addressed review comments from Jan Beulich <jbeulich@suse.com> > - Disable decodes before writing ~0 to BARs > - Enable BUS MASTER at the end along with decode bits > > Changes in v3: > - Retained enabling of BUS master for all device functions as > was in original commit > > Changes in v2: > - BUS MASTER state was captured and restored to the same state > while enabling decode bits. > --- > --- > tools/firmware/hvmloader/pci.c | 49 +++++++++++++++++++++++++++++++----------- > 1 file changed, 36 insertions(+), 13 deletions(-) > > diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c > index 0b708bf578..47cba69ce4 100644 > --- a/tools/firmware/hvmloader/pci.c > +++ b/tools/firmware/hvmloader/pci.c > @@ -84,6 +84,7 @@ void pci_setup(void) > uint32_t vga_devfn = 256; > uint16_t class, vendor_id, device_id; > unsigned int bar, pin, link, isa_irq; > + uint8_t pci_devfn_decode_type[256] = {}; > > /* Resources assignable to PCI devices via BARs. */ > struct resource { > @@ -120,6 +121,13 @@ void pci_setup(void) > */ > bool allow_memory_relocate = 1; > > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != > + PCI_COMMAND_IO); > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != > + PCI_COMMAND_MEMORY); > + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER != > + PCI_COMMAND_MASTER); > + These don't align. Looks like you used an indent of 8 which seems entirely arbitrary. The rest LGTM. Paul
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c index 0b708bf578..47cba69ce4 100644 --- a/tools/firmware/hvmloader/pci.c +++ b/tools/firmware/hvmloader/pci.c @@ -84,6 +84,7 @@ void pci_setup(void) uint32_t vga_devfn = 256; uint16_t class, vendor_id, device_id; unsigned int bar, pin, link, isa_irq; + uint8_t pci_devfn_decode_type[256] = {}; /* Resources assignable to PCI devices via BARs. */ struct resource { @@ -120,6 +121,13 @@ void pci_setup(void) */ bool allow_memory_relocate = 1; + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO != + PCI_COMMAND_IO); + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MEMORY != + PCI_COMMAND_MEMORY); + BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_MASTER != + PCI_COMMAND_MASTER); + s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL); if ( s ) allow_memory_relocate = strtoll(s, NULL, 0); @@ -208,6 +216,20 @@ void pci_setup(void) break; } + /* + * It is recommended that BAR programming be done whilst decode + * bits are cleared to avoid incorrect mappings being created. + * When 64-bit memory BAR is programmed, first by writing the + * lower half and then the upper half, which maps to an address + * under 4G, as soon as lower half is wriiten, replacing any RAM + * mapped in that address, which is not restored back after the + * upper half is written and PCI memory is correctly mapped to + * its intended high mem address. + */ + cmd = pci_readw(devfn, PCI_COMMAND); + cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO); + pci_writew(devfn, PCI_COMMAND, cmd); + /* Map the I/O memory and port resources. */ for ( bar = 0; bar < 7; bar++ ) { @@ -289,10 +311,8 @@ void pci_setup(void) devfn>>3, devfn&7, 'A'+pin-1, isa_irq); } - /* Enable bus mastering. */ - cmd = pci_readw(devfn, PCI_COMMAND); - cmd |= PCI_COMMAND_MASTER; - pci_writew(devfn, PCI_COMMAND, cmd); + /* Enable bus master for this function later */ + pci_devfn_decode_type[devfn] = PCI_COMMAND_MASTER; } if ( mmio_hole_size ) @@ -497,16 +517,12 @@ void pci_setup(void) PRIllx_arg(bar_sz), bar_data_upper, bar_data); - - /* Now enable the memory or I/O mapping. */ - cmd = pci_readw(devfn, PCI_COMMAND); if ( (bar_reg == PCI_ROM_ADDRESS) || ((bar_data & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) ) - cmd |= PCI_COMMAND_MEMORY; + pci_devfn_decode_type[devfn] |= PCI_COMMAND_MEMORY; else - cmd |= PCI_COMMAND_IO; - pci_writew(devfn, PCI_COMMAND, cmd); + pci_devfn_decode_type[devfn] |= PCI_COMMAND_IO; } if ( pci_hi_mem_start ) @@ -526,10 +542,17 @@ void pci_setup(void) * has IO enabled, even if there is no I/O BAR on that * particular device. */ - cmd = pci_readw(vga_devfn, PCI_COMMAND); - cmd |= PCI_COMMAND_IO; - pci_writew(vga_devfn, PCI_COMMAND, cmd); + pci_devfn_decode_type[vga_devfn] |= PCI_COMMAND_IO; } + + /* Enable bus master, memory and I/O decode for all valid functions. */ + for ( devfn = 0; devfn < 256; devfn++ ) + if ( pci_devfn_decode_type[devfn] ) + { + cmd = pci_readw(devfn, PCI_COMMAND); + cmd |= pci_devfn_decode_type[devfn]; + pci_writew(devfn, PCI_COMMAND, cmd); + } } /*
It was observed that PCI MMIO and/or IO BARs were programmed with memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled, during PCI setup phase. This resulted in incorrect memory mapping as soon as the lower half of the 64 bit bar is programmed. This displaced any RAM mappings under 4G. After the upper half is programmed PCI memory mapping is restored to its intended high mem location, but the RAM displaced is not restored. The OS then continues to boot and function until it tries to access the displaced RAM at which point it suffers a page fault and crashes. This patch address the issue by deferring enablement of memory and I/O decode in command register until all the resources, like interrupts I/O and/or MMIO BARs for all the PCI device functions are programmed, in the descending order of memory requested. Signed-off-by: Harsha Shamsundara Havanur <havanur@amazon.com> --- Changes in v5: - Fix style and comment - Enable Bus master for all valid device functions Changes in v4: Addressed review comments from Jan Beulich <jbeulich@suse.com> - Disable decodes before writing ~0 to BARs - Enable BUS MASTER at the end along with decode bits Changes in v3: - Retained enabling of BUS master for all device functions as was in original commit Changes in v2: - BUS MASTER state was captured and restored to the same state while enabling decode bits. --- --- tools/firmware/hvmloader/pci.c | 49 +++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 13 deletions(-)