Re: em problem in virtualbox since the weekend

On Thursday, July 21, 2011 6:37:05 pm Jung-uk Kim wrote:
> On Thursday 21 July 2011 11:53 am, John Baldwin wrote:
> > On Wednesday, July 20, 2011 6:22:33 pm Steve Wills wrote:
> > > On 07/20/11 09:04, John Baldwin wrote:
> > > > On Wednesday, July 20, 2011 8:33:07 am Bernhard Froehlich wrote:
> > > >> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote:
> > > >>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> While testing some other things, I found -CURRENT from
> > > >>>> yesterday doesn't work with the em0 in my VirtualBox 4.0.8
> > > >>>> (a little out of date admittedly). It worked Friday or
> > > >>>> Saturday I think. Anyone else seen this or should I open a
> > > >>>> PR? Has the code changed or am I perhaps misremembering
> > > >>>> dates? The error reported is:
> > > >>>>
> > > >>>> em0: Unable to allocate bus resource: memory
> > > >>>> em0: Allocation of PCI resources failed
> > > >>>
> > > >>> This is due to a bug in VirtualBox's BIOS implementation. 
> > > >>> Someone should file
> > > >>> a bug report with VirtualBox to ask them to fix their BIOS. 
> > > >>> The problem is that they claim that the Host-PCI bridge in
> > > >>> their system only decodes addresses 0xa0000-0xbffff (i.e. the
> > > >>> VGA window) via the "Producer" resources in the _CRS method
> > > >>> of the Host-PCI bridge device.  This tells the OS that all
> > > >>> the existing PCI devices are using invalid memory address
> > > >>> ranges but that there is also no available address space to
> > > >>> allocate for PCI devices such as em0.
> > > >>>
> > > >>> You can workaround this by setting
> > > >>> "debug.acpi.disabled=hostres" until VirtualBox fixes their
> > > >>> code.  I'm happy to provide further clarification to an
> > > >>> existing VirtaulBox bug report if needed.
> > > >>
> > > >> Thanks a lot for the analysis! I've talked to one of the
> > > >> virtualbox developers about that but they are not aware of
> > > >> such problems with Linux or Windows guests yet. So they are
> > > >> currently unsure if it's a VirtualBox or FreeBSD fault and if
> > > >> it's their fault why it works fine with other guests. I'm also
> > > >> unsure because I haven't heard of that problem before and now
> > > >> multiple people complain. That looks more like a FreeBSD
> > > >> related problem on current or stable.
> > > >>
> > > >> I think it would be good if someone could try to reproduce
> > > >> that with emulators/virtualbox-ose-legacy which is 3.2.12 to
> > > >> get some vbox dev look into the problem again.
> > > >
> > > > FreeBSD just started honoring this setting in the BIOS this
> > > > week and ignored it previously.  Can you get an acpidump from
> > > > within VirtaulBox?  I might be able to point to a bug in it
> > > > directly if so.
> > >
> > > Thanks for the info! I've attached the acpidump and also posted a
> > > copy here:
> > >
> > > http://people.freebsd.org/~swills/vbox-4.0.8.asl.gz
> > >
> > > in case the mailing list eats it.
> >
> > Hmm, so there does look to be a reasonable _CRS method.  Oh, I
> > think I see what I don't like:
> >
> >                 DWordMemory (ResourceProducer, PosDecode,
> > MinNotFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000,         //
> > Granularity
> >                     0x00000000,         // Range Minimum
> >                     0xFFDFFFFF,         // Range Maximum
> >                     0x00000000,         // Translation Offset
> >                     0x00000000,         // Length
> >                     ,, _Y01, AddressRangeMemory, TypeStatic)
> > It should be using MinFixed, not MinNotFixed.
> 
> Actually, I am responsible for this:
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/virtualbox-
ose/files/Attic/patch-src-VBox-Devices-PC-vbox.dsl?rev=1.1;content-
type=text%2Fplain
> 
> I believe this patch was submitted upstream later.
> 
> > Author: jhb
> > Date: Thu Jul 21 20:43:43 2011
> > New Revision: 224254
> > URL: http://svn.freebsd.org/changeset/base/224254
> > 
> > Log:
> >   Allow non-fixed endpoints for a producer address range if the
> >   length of the resource covers the entire range.  Some BIOSes
> >   appear to mark endpoints as non-fixed incorrectly (non-fixed
> >   endpoints are supposed to be used in _PRS when OSPM is allowed to
> >   allocate a certain chunk of address space within a larger range, I
> >   don't believe it is supposed to be used for _CRS).
> 
> No, _CRS can use MinNotFixed (and MaxNotFixed).  You can find similar 
> examples from ACPI spec.

Err, this is clearly illegal.  Consult Table 6-38 from ACPI Spec 3.0b (page 
213, actual page 233 in the PDF).  If the _LEN of an Address Space Descriptor 
is > 0, then _MIF (Min Fixed) must equal _MAF (Max Fixed).  Having one fixed 
and not the other is explicitly marked "illegal".

Furthermore, the case where _MIF == _MAF == 0 has this description:

  Fixed size, variable location resource descriptor for _PRS.
  _LEN must be a multiple of (_GRA + 1).
  OS can pick the resource range that satisfies following conditions:

    * Start address is a multiple of (_GRA + 1) and greater or equal to _MIN.
    * End address is (start_address + _LEN - 1) and less or equal to _MAX.

That explicitly states that this is _only_ for _PRS.  Thus, the only valid
combination for _CRS for _MIF and _MAF with a length != 0 is to have both
endpoints fixed.

Further, note that for the case were _LEN is zero, all valid cases are 
described by a block starting thus:

  Variable size, variable location resource descriptor for _PRS.

Given this, the _only_ valid combination for _CRS is Length != 0, and _MIF == 
_MAF == 1.  All other resources in _CRS are illegal.

BTW, this same table is reproduced verbatim in 4.0a (now table 6-40 on page 
260).

-- 
John Baldwin