qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kevin@koconnor.net, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 3/5] Use the correct mask to size the PCI option ROM BAR.
Date: Mon, 12 Oct 2009 14:08:57 +0200	[thread overview]
Message-ID: <20091012120857.GI16702@redhat.com> (raw)
In-Reply-To: <20091012115916.GA12834@redhat.com>

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.

> > Section 6.2.5.2 says:
> > Device independent configuration software can determine how much address
> > space the device requires by writing a value of all 1's to the address
> > portion of the register and then reading the value back. (address
> > portion are bits 31-11).
> 
> We must also save and restore the lower bits.
> 
> > So we should write PCI_ROM_ADDRESS_MASK in case of ROM and 0xffffffff
> > in case of regular BAR.
> > 
> > > See also Qemu pcbios commit 6ddb9f5c742b2b82b1755d7ec2a127f6e20e3806
> > > 
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > >  src/pciinit.c |    8 +++++---
> > >  1 files changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/src/pciinit.c b/src/pciinit.c
> > > index 1d0f784..29b3901 100644
> > > --- a/src/pciinit.c
> > > +++ b/src/pciinit.c
> > > @@ -139,11 +139,13 @@ static void pci_bios_init_device(u16 bdf)
> > >              int ofs;
> > >              u32 val, size;
> > >  
> > > -            if (i == PCI_ROM_SLOT)
> > > +            if (i == PCI_ROM_SLOT) {
> > >                  ofs = PCI_ROM_ADDRESS;
> > > -            else
> > > +                pci_config_writel(bdf, ofs, PCI_ROM_ADDRESS_MASK);
> > > +            } else {
> > >                  ofs = PCI_BASE_ADDRESS_0 + i * 4;
> > > -            pci_config_writel(bdf, ofs, 0xffffffff);
> > > +                pci_config_writel(bdf, ofs, PCI_BASE_ADDRESS_IO_MASK);
> > > +            }
> > >              val = pci_config_readl(bdf, ofs);
> > >              if (val != 0) {
> > >                  size = (~(val & ~0xf)) + 1;
> > > -- 
> > > 1.6.3.3
> > > 
> > > 
> > 
> > --
> > 			Gleb.

--
			Gleb.

  reply	other threads:[~2009-10-12 12:09 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-11 18:59 [Qemu-devel] [PATCH 1/5] Generate mptable unconditionally Gleb Natapov
2009-10-11 18:59 ` [Qemu-devel] [PATCH 2/5] Enable power button event generation Gleb Natapov
2009-10-11 18:59 ` [Qemu-devel] [PATCH 3/5] Use the correct mask to size the PCI option ROM BAR Gleb Natapov
2009-10-11 21:53   ` [Qemu-devel] " Michael S. Tsirkin
2009-10-12  6:50     ` Gleb Natapov
2009-10-12  9:52       ` Michael S. Tsirkin
2009-10-12 10:08         ` Gleb Natapov
2009-10-12 11:03           ` Michael S. Tsirkin
2009-10-12 11:45             ` Michael S. Tsirkin
2009-10-12 11:48             ` Gleb Natapov
2009-10-12 11:59               ` Michael S. Tsirkin
2009-10-12 12:08                 ` Gleb Natapov [this message]
2009-10-12 13:20                   ` Michael S. Tsirkin
2009-10-12 13:29                     ` Gleb Natapov
2009-10-12 13:51                       ` Michael S. Tsirkin
2009-10-12 14:04                         ` Gleb Natapov
2009-10-12 14:11                           ` Michael S. Tsirkin
2009-10-12 14:17                             ` Gleb Natapov
2009-10-12 14:24                               ` Michael S. Tsirkin
2009-10-12 14:20                     ` [Qemu-devel] seabios: fix low bits in ROM and I/O sizing Michael S. Tsirkin
2009-10-13 13:39                       ` [Qemu-devel] " Gleb Natapov
2009-10-14 23:29                         ` Kevin O'Connor
2009-10-11 18:59 ` [Qemu-devel] [PATCH 4/5] Make MMIO address page aligned in guest Gleb Natapov
2009-10-11 21:48   ` [Qemu-devel] " Michael S. Tsirkin
2009-10-12  6:44     ` Gleb Natapov
2009-10-12  7:10       ` Michael S. Tsirkin
2009-10-12  7:22         ` Gleb Natapov
2009-10-12  8:13           ` Michael S. Tsirkin
2009-10-12  8:48             ` Gleb Natapov
2009-10-12  9:43               ` Michael S. Tsirkin
2009-10-12 10:06                 ` Gleb Natapov
2009-10-12 14:27   ` Kevin O'Connor
2009-10-11 18:59 ` [Qemu-devel] [PATCH 5/5] Set the PCI base address to 0xf0000000 Gleb Natapov
2009-10-12 14:24   ` [Qemu-devel] " Kevin O'Connor

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=20091012120857.GI16702@redhat.com \
    --to=gleb@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).