Date: Mon, 06 Apr 2009 11:17:55 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org, babkin@verizon.net, ivoras@FreeBSD.org Subject: Re: Patch for MS Hyper V (virtualization) Message-ID: <20090406.111755.1973602189.imp@bsdimp.com> In-Reply-To: <200904061154.19601.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200904061154.19601.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
: >
: > Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote:
: > >Can someo=ne please review and commit (if appropriate) the tweak for
: > >Hyper-V shu=tdown issue at
: > http://shell.peach.ne.jp/aoyama/archives/40
: > >?
: > >
: > =>>The problem is: the VM appears to hang on shutdown without it
: > (hanging
: > >the Hyper-V VM with it so the host also can't shutdown or reboot
: > >re=liably - someone at MS skipped the part where an error in the VM
: > >isn't=supposed to bring the host down with it)
: > I don't have the commit =permission any more but I can review :-)
: > Yes, Hyper-V does not like th=e writes into the PCI config space.
Why not? We need to understand exactly what it doesn't like because
this is non-standard compliant behavior.
: > Very specifically,
: > writing the base=register window address of the simulated 21140
: > screws up something
: > tha=t prevents the VM from shutting down. Interestingly, even reading
: > and writi=ng
: > back the same value has this effect. So the patch is valid.
Then the Hyper-V is broken. This is bog-standard PCI behavior. The
OS must be able to write to the BARs to size the resource being
decoded. In addition, the OS is allowed to move the location of an
allocation for a BAR, so avoiding writes to it is bad. Finally, some
BIOSes don't allocate resources for a card, and this would totally
prevent 21140's from being usable on those machines.
: > =>I don't particularly like the hackish checking for the 21140 chip,
: > and I'=m not sure
: > if if would break some real 21140 chip out there. If the dri=ver does
: > the same as another
: > one I've seen, the driver tries to align t=he register window to
: > 0x80, and in the
: > simulated 21140 it's already ali=gned. I've had a quick look but
: > couldn't say it
: > for sure. I'd do it dif=ferently: check if the value being written is
: > the same that was read,
: > =and skip the write in this case.
: > Let me see, maybe I'll make a dif=ferent patch.
:
: Hmm, the problem is we need to be able to write to BARs to size them. Any OS
: needs to be able to do this to know what address space regions are being
: decoded by devices. We can't avoid writing to BARs.
Exactly. Not only do we have to read/write them to size the BAR
resource, but as I indicated above, one must write to them when the
BIOS doesn't assign resources to the BAR and the driver requests that
resource.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090406.111755.1973602189.imp>