From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 15:12:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ADAC106564A; Tue, 7 Apr 2009 15:12:55 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id EC4B58FC08; Tue, 7 Apr 2009 15:12:54 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms124.mailsrvcs.net ([172.18.12.134]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHQ006THKX8DDII@vms173001.mailsrvcs.net>; Tue, 07 Apr 2009 10:12:44 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms124.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 07 Apr 2009 10:12:44 -0500 (CDT) Date: Tue, 07 Apr 2009 10:12:44 -0500 (CDT) From: Sergey Babkin To: jhb@freebsd.org Message-id: <365687070.340074.1239117164323.JavaMail.root@vms124.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Tue, 07 Apr 2009 16:07:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, babkin@verizon.net, ivoras@freebsd.org Subject: Re: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:12:55 -0000 (Let's see if I've figured yet another workaround for the web interface= ). The address space used by the card I think is actually 0x80 bytes= , in the I/O port space. The card has it located at the port 0xEC00. Yester= day I've had all the values and addresses written to this card's registers = printed for debugging and I don't remember seeing all ones written to this = register. It was writing back first 0xEC01 (1 is the I/O space indicator), = then 0xEC00. And no, the culprit is not the missing bit 0 (which should be = read-only by the PCI spec): I've tried adding it back, and it made no diffe= rence. I'll try FreeBSD 8 and see what happens. -SB Ap= r 7, 2009 10:28:50 AM, [1]jhb@freebsd.org wrote: On Monday 06 April 2009 11:12:33= pm Sergey Babkin wrote: > John Baldwin wrote: > > > = > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > >= 2009/4/6 John Baldwin <[2]jhb@freebsd.org>: > >= ; > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: >= ; > > > > > > Hmm, the problem is we need to be able t= o write to BARs to size them. =D0=B1 Any > > OS > > &= gt; > needs to be able to do this to know what address space regions are= being > > > > decoded by devices. =D0=B1 We can't avoid= writing to BARs. > > > > > > I have only vague ide= a what BARs are and if it's the correct diagnosis > > > in this= case, but the fact is that other operating systems (Windows, > > = > Linux tested) work, so either there is a way around it or the original= > > > premise is wrong-ish. > > > > Every O= S writes to BARs to size them during boot. It's the defined procedure<= br>> > for sizing them. A BAR is a base address register, and it is = how a PCI > > device gets memory and I/O port resources. OS (or B= IOS) writes a starting > > address into the register to tell the P= CI device where a given > > resource "starts". > > Th= e OS doesn't have to write to the BAR if BIOS has already > done it. = And the BIOS in the Hyper-V VM is obviously special, > so it doesn't = trip on iself. Yes it does because we don't know how _big_ the BAR = is. The OS has to know if the device is decoding 1MB or 64KB because w= e need to reserve the entire window to prevent any other devices from u= sing it. We don't just write the existing value, we write all 1's to i= t and read it back. The lower N bits "stick" at zero and we use that t= o figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c > Anyway, as far as I can tell, it's only the base register of = > the simulated DEC21140 device that has this issue, so it's > qu= ite possible that the bug is in that device's simulator. > > = I've attached a modified patch that checks conservatively for this > = precise situation, so it should not break compatibility with > anythi= ng else. I've tested it on Hyper-V. Can you test unmodified FreeBSD = 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding vi= a the PCI command register while sizing BARs that may address this. = -- John Baldwin References 1. 3D"mailto:jhb@freebsd.org" 2. 3D"mailto:jhb@freebsd.org"