qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 3/5] Use the correct mask to size the PCI option


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH 3/5] Use the correct mask to size the PCI option ROM BAR.
Date: Mon, 12 Oct 2009 15:20:27 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Mon, Oct 12, 2009 at 02:08:57PM +0200, Gleb Natapov wrote:
> On Mon, Oct 12, 2009 at 01:59:16PM +0200, Michael S. Tsirkin wrote:
> > On Mon, Oct 12, 2009 at 01:48:41PM +0200, Gleb Natapov wrote:
> > > On Mon, Oct 12, 2009 at 01:03:36PM +0200, Michael S. Tsirkin wrote:
> > > > On Mon, Oct 12, 2009 at 12:08:21PM +0200, Gleb Natapov wrote:
> > > > > On Mon, Oct 12, 2009 at 11:52:25AM +0200, Michael S. Tsirkin wrote:
> > > > > > On Mon, Oct 12, 2009 at 08:50:24AM +0200, Gleb Natapov wrote:
> > > > > > > Send patch with your favorite interpretation to qemu 
> > > > > > > pcbios/seabios.
> > > > > > > The regression concern from my previous mail applicable here as 
> > > > > > > well.
> > > > > > 
> > > > > > Okay. Can you ack the following?
> > > > > > 
> > > > > I can if you'll add PCI spec reference for me to double check.
> > > > 
> > > > 
> > > > > Also I prefer strict spec reading :)
> > > > 
> > > > OK, the issue is that reserved bits in BARs are not
> > > > defined as read-only.  So here's a strict one:
> > > > can you ack?
> > > > 
> > > > --->
> > > > 
> > > > seabios: fix ROM and I/O sizing
> > > > 
> > > > For ROM BARs, bit 0 is writeable (enable bit), which we not
> > > > only don't want to set, but it will stick and make us think
> > > > it's an I/O port resource.
> > > > Further, PCI spec defines the following bits as reserved:
> > > > - bit 1 in I/O BAR
> > > > - bits 10:1 in ROM BAR
> > > > and we should be careful and write 0 there.
> > > > For memory, bits 0-3 are reserved, so it's safe to handle it
> > > > in the same way as I/O.
> > > > 
> > > > See 6.2.5.1 for I/O and memory, and 6.2.5.2 for ROM;
> > > > pages 225 and 228 in PCI spec revision 3.0.
> > > > 
> > > Section 6.2.5.1 says:
> > > Software saves the original value of the Base Address register, writes
> > > 0 FFFF FFFFh to the register, then reads it back.
> > 
> > I think you miss something.  Here it is in full:
> > 
> >     Decode (I/O or memory) of a register is disabled via the command 
> > register before sizing a
> >     Base Address register. Software saves the original value of the Base 
> > Address register, writes
> >     0 FFFF FFFFh to the register, then reads it back. Size calculation can 
> > be done from the
> >     32-bit value read by first clearing encoding information bits (bit 0 
> > for I/O, bits 0-3 for
> >     memory), inverting all 32 bits (logical NOT), then incrementing by 1. 
> > The resultant 32-bit
> >     value is the memory/I/O range size decoded by the register. Note that 
> > the upper 16 bits of
> >     the result is ignored if the Base Address register is for I/O and bits 
> > 16-31 returned zero
> >     upon read. The original value in the Base Address register is restored 
> > before re-enabling
> >     decode in the command register of the device.
> > 
> > Note the bit about restoring back the original value.
> > You can not assume that reserved bits are read-only.
> > 
> I assume nothing. I am saying the code was correct in writing 0xffffffff
> there. If coded does not restore original value that is another issue.


Right. And there's another bug that I see and that is that size for I/O
BAR was calculated incorrectly: val & ~0xf is wrong for I/O as the size
could be 4 bytes.  So here's a patch that addresses all 3 issues:
Ack?

---->

Subject: [PATCH] seabios: fix low bits in ROM and I/O sizing

This cleans up handling of low bits during BAR sizing,
to match PCI spec requirements, and to use symbolic
constants from pci_regs.h

Issues fixed:
For ROM BARs, bit 0 is writeable (enable bit), which we not
only don't want to set, but it will stick and make us think
it's an I/O port resource.
Further, PCI spec defines the following bits as reserved:
- bit 1 in I/O BAR
- bits 10:1 in ROM BAR
and we should be careful and preserve any values there.
Bits 3:2 in I/O BAR might be writeable, so it
is wrong to mask them when calculating BAR size.

Spec references:
See 6.2.5.1 for I/O and memory, and 6.2.5.2 for ROM,
6.1 for reserved bit handling;
pages 225, 228 and 214 in PCI spec revision 3.0.

See also Qemu pcbios commit 6ddb9f5c742b2b82b1755d7ec2a127f6e20e3806

Original-by: Gleb Natapov <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>

diff --git a/src/pciinit.c b/src/pciinit.c
index 7d2ea00..f9ebd61 100644
--- a/src/pciinit.c
+++ b/src/pciinit.c
@@ -136,16 +136,23 @@ static void pci_bios_init_device(u16 bdf)
         /* default memory mappings */
         for (i = 0; i < PCI_NUM_REGIONS; i++) {
             int ofs;
-            u32 val, size;
-
+            u32 val, mask, size;
             if (i == PCI_ROM_SLOT)
                 ofs = PCI_ROM_ADDRESS;
             else
                 ofs = PCI_BASE_ADDRESS_0 + i * 4;
-            pci_config_writel(bdf, ofs, 0xffffffff);
+
+            val = pci_config_readl(bdf, ofs);
+            if (i == PCI_ROM_SLOT)
+               mask = PCI_ROM_ADDRESS_MASK;
+            else if (val & PCI_BASE_ADDRESS_SPACE_IO)
+                mask = PCI_BASE_ADDRESS_IO_MASK;
+            else
+                mask = PCI_BASE_ADDRESS_MEM_MASK;
+            pci_config_writel(bdf, ofs, val | mask);
             val = pci_config_readl(bdf, ofs);
             if (val != 0) {
-                size = (~(val & ~0xf)) + 1;
+                size = (~(val & mask)) + 1;
                 if (val & PCI_BASE_ADDRESS_SPACE_IO)
                     paddr = &pci_bios_io_addr;
                 else if (size >= 0x04000000)
-- 
1.6.5.rc2






reply via email to

[Prev in Thread] Current Thread [Next in Thread]