From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsiTo-0005jY-RC for qemu-devel@nongnu.org; Tue, 29 Sep 2009 15:35:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsiTj-0005iT-D2 for qemu-devel@nongnu.org; Tue, 29 Sep 2009 15:35:19 -0400 Received: from [199.232.76.173] (port=55708 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsiTj-0005iQ-5m for qemu-devel@nongnu.org; Tue, 29 Sep 2009 15:35:15 -0400 Received: from mail-bw0-f225.google.com ([209.85.218.225]:64132) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsiTi-0006c6-LS for qemu-devel@nongnu.org; Tue, 29 Sep 2009 15:35:14 -0400 Received: by bwz25 with SMTP id 25so4362741bwz.8 for ; Tue, 29 Sep 2009 12:35:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090929155756.GA13666@redhat.com> References: <4ABF52A5.5080409@redhat.com> <4ABF585D.7000201@redhat.com> <20090927140841.GA24769@redhat.com> <4ABF7359.8050404@redhat.com> <20090927142129.GA24851@redhat.com> <20090927142422.GB24851@redhat.com> <20090929145006.GA3301@redhat.com> <20090929155756.GA13666@redhat.com> From: Blue Swirl Date: Tue, 29 Sep 2009 22:34:53 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCHv2] qemu: target library, use it in msix Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Avi Kivity , qemu-devel@nongnu.org On Tue, Sep 29, 2009 at 6:57 PM, Michael S. Tsirkin wrote: > On Tue, Sep 29, 2009 at 06:15:21PM +0300, Blue Swirl wrote: >> On Tue, Sep 29, 2009 at 5:50 PM, Michael S. Tsirkin wro= te: >> > On Sun, Sep 27, 2009 at 06:19:05PM +0300, Blue Swirl wrote: >> >> On Sun, Sep 27, 2009 at 5:24 PM, Michael S. Tsirkin = wrote: >> >> > On Sun, Sep 27, 2009 at 04:21:29PM +0200, Michael S. Tsirkin wrote: >> >> >> On Sun, Sep 27, 2009 at 04:14:49PM +0200, Avi Kivity wrote: >> >> >> > On 09/27/2009 04:08 PM, Michael S. Tsirkin wrote: >> >> >> >> >> >> >> >> >> >> >> >>>> In practice, the only user is now msix and it does not. =C2= =A0It has 0x1000 >> >> >> >>>> as a constant parameter. =C2=A0For target_phys_addr_t users i= f we ever have >> >> >> >>>> them, we'll just add target_phys_page_align. Generally it's u= nusual for >> >> >> >>>> devices to care about size of target physical page. >> >> >> >>>> >> >> >> >>>> >> >> >> >>> I'd fill better with uint64_t, at least that won't truncate. >> >> >> >>> >> >> >> >> Doesn't naming it target_page_align32 address this concern? >> >> >> >> >> >> >> > >> >> >> > How can the caller (except in your special case) know if it has = a >> >> >> > quantity that will fit in 32 bits? >> >> >> >> >> >> It's actually not unusual for devices to limit addressing to 32 bi= t, whatever >> >> >> the bus supports. >> >> > >> >> > I would say that devices normally have a specific addressing, and s= hould >> >> > not be using target specific types at all. =C2=A0This alignment to = target >> >> > page size is actually an unusual thing. >> >> >> >> Actually, AFAICT MSI-X spec (6.8.2, from the MSI entry in Wikipedia) >> >> only requires a QWORD alignment. There is some blurb about 4k >> >> alignment, but I think it only describes how software should use the >> >> structure. >> >> If this is the case, we could drop the whole target page >> >> stuff. >> > >> > The variable MSIX_PAGE_SIZE actually specifies the size of the space >> > allocated for MSIX in the memory region. =C2=A0Spec requires locating = MSI-X >> > tables in a 4K region separate from any other device register, so from >> > that point of view we could just have had >> > #define MSIX_PAGE_SIZE 0x1000 >> >> Can you cite the spec, I only found the QWORD stuff. > > In spec revision 3.0, see this text: > > =C2=A0 =C2=A0 =C2=A0 =C2=A06.8.2. =C2=A0MSI-X Capability and Table Struct= ures > > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > =C2=A0 =C2=A0 =C2=A0 =C2=A0If a Base Address register that maps address s= pace for the MSI-X Table or MSI-X PBA also > =C2=A0 =C2=A0 =C2=A0 =C2=A0maps other usable address space that is not as= sociated with MSI-X structures, locations (e.g., > =C2=A0 =C2=A0 =C2=A0 =C2=A0for CSRs) used in the other address space must= not share any naturally aligned 4-KB address > =C2=A0 =C2=A0 =C2=A0 =C2=A0range with one where either MSI-X structure re= sides. This allows system software where > =C2=A0 =C2=A0 =C2=A0 =C2=A0applicable to use different processor attribut= es for MSI-X structures and the other address I think these are instructions for writing system software, not description on how MSI-X hardware needs the tables laid out. That means, the tables should use page alignment (in order to support some CPU attributes), but the hardware only cares that the data is QWORD aligned.