Re: [XEN PATCH v2] hvmloader: Enable MMIO and I/O decode, after all resource allocation

["Shamsundara Havanur, Harsha" <havanur@xxxxxxxxxx>]

On Tue, 2020-04-14 at 09:42 +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 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
> > It was observed that PCI MMIO and/or IO BARs were programmed with
> > BUS master, memory and I/O decodes (bits 0,1 and 2 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, which displaced any RAM mappings under 4G. After the
> > upper half is programmed PCI memory mapping is restored to its
> > intended mapping 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.
> > 
> > Signed-off-by: Harsha Shamsundara Havanur <havanur@xxxxxxxxxx>
> > Reviewed-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> > Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > ---
> >  tools/firmware/hvmloader/pci.c | 35 +++++++++++++++++++++++++++---
> > -----
> >  1 file changed, 27 insertions(+), 8 deletions(-)
> 
> There not being any description of what has changed in v2, I also
> can't easily judge whether keeping the two tags above was
> legitimate. In any event you don't seem to have taken care of all
> review feedback (whether by making changes to the patch or by
> replying verbally).
> 
> > --- 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,9 @@ void pci_setup(void)
> >       */
> >      bool allow_memory_relocate = 1;
> > 
> > +    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_IO !=
> > PCI_COMMAND_IO);
> > +    BUILD_BUG_ON((typeof(*pci_devfn_decode_type))PCI_COMMAND_IO !=
> > PCI_COMMAND_MASTER);
> 
This is a mistake, In fact it should be compared against unit8 as I am
storing whole command value later in the loop.

> This looks like a copy-and-paste mistake - are you sure you've
> build-tested this? (This alone likely invalidates the tags, as
> per above.)
> 
> > @@ -289,9 +293,22 @@ void pci_setup(void)
> >                     devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
> >          }
> > 
> > -        /* Enable bus mastering. */
> > +        /*
> > +         * Disable bus mastering, memory and I/O space, which is
> > typical device
> > +         * reset state. 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 first maps to an address
> > under 4G
> > +         * 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.
> > +         *
> > +         * Capture the state of bus master to restore it back once
> > BAR
> > +         * programming is completed.
> > +         */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > -        cmd |= PCI_COMMAND_MASTER;
> > +        pci_devfn_decode_type[devfn] = cmd & ~(PCI_COMMAND_MEMORY
> > | PCI_COMMAND_IO);
> > +        cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY |
> > PCI_COMMAND_IO);
> 
> The disabling of MASTER was put under question in v1 already.

Disabling of MASTER is done whilst programming BARs and it is restored
back to its previous value in the loop at the end of pci_setup
function.

> 
> > @@ -526,10 +542,13 @@ 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 memory and I/O space. Restore saved BUS MASTER state
> > */
> > +    for ( devfn = 0; devfn < 256; devfn++ )
> > +        if ( pci_devfn_decode_type[devfn] )
> > +            pci_writew(devfn, PCI_COMMAND,
> > pci_devfn_decode_type[devfn]);
> 
> You effectively clear the upper 8 bits here, rather than retaining
> them.
> 
In fact cmd is a 32 bit value and I am retaining only lower 8 bits of
it. This will be corrected in v3.
> Jan